Bytea binary compatible

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Here is a patch to make bytea binary compatible with other text data
types. Comments?

No way! Unless you propose to make the text types null-safe (which
would mean such nontrivial projects as replacing strcoll()).

The fact that the storage formats are both struct varlena does not
mean that these types are interchangeable. I fail to see where it'd
be a good idea to mark them binary-compatible, even if there weren't
serious implementation issues.

regards, tom lane

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Here is a patch to make bytea binary compatible with other text data
types. Comments?

No way! Unless you propose to make the text types null-safe (which
would mean such nontrivial projects as replacing strcoll()).

The fact that the storage formats are both struct varlena does not
mean that these types are interchangeable. I fail to see where it'd
be a good idea to mark them binary-compatible, even if there weren't
serious implementation issues.

OK, code backed out. If the storage formats are the same, doesn't that
make them binary compatibile. I know the NULL issue though. I think I
see what you mean, that a text function can't operate on a bytea field.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> writes:

OK, code backed out. If the storage formats are the same, doesn't that
make them binary compatibile.

No, because one allows nulls and the other doesn't. If you disregard
what are legal values and what aren't, then every pair of varlena
datatypes we have could be called "binary compatible".

More to the point, though, why *should* they be marked binary
compatible? I saw no compelling reason advanced for it, and I can see a
couple of compelling reasons not to. Every binary-compatible pairing is
another hole in our type system, another opportunity for unexpected
behavior. We shouldn't add them on whims. Especially we shouldn't add
them for datatypes that aren't even of the same family. bytea isn't for
storage of textual data, and so it makes little sense to allow
application of textual operations to it.

regards, tom lane

Bruce Momjian <pgman@candle.pha.pa.us> writes:

OK, code backed out. If the storage formats are the same, doesn't that
make them binary compatibile.

No, because one allows nulls and the other doesn't. If you disregard
what are legal values and what aren't, then every pair of varlena
datatypes we have could be called "binary compatible".

More to the point, though, why *should* they be marked binary
compatible? I saw no compelling reason advanced for it, and I can see a
couple of compelling reasons not to. Every binary-compatible pairing is
another hole in our type system, another opportunity for unexpected
behavior. We shouldn't add them on whims. Especially we shouldn't add
them for datatypes that aren't even of the same family. bytea isn't for
storage of textual data, and so it makes little sense to allow
application of textual operations to it.

I have no idea why the user wanted it. I suppose it was so he could
pass text/varchar to bytea and back again. Seems he has to convert it,
which makes sense about the NULLs.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> writes:

OK, code backed out. If the storage formats are the same, doesn't that
make them binary compatibile.

Actually, I didn't mean to even apply the bytea patch I backed out. It
accidentally got when I applied RESET ALL and I only realized it later.
I had the diff in a separate file so it was easy to back out.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026