"Joe Conway" <joseph.conway@home.com> writes:
> Well, ISTM the simplest (if not the most efficient) way to do bytea-to-text
> would be a function that takes the escaped string value from byteaout, and
> creates a text value directly from it. The only danger I can think of is
> that very long strings might need to be truncated in length, since the
> escaped string could be significantly longer than the binary.
> Text-to-bytea should be a straight copy, since nothing that can be
> represented as text cannot be represented as bytea.
Ugh ... if the conversion functions are not inverses then I think they
lose much of their value. I could see doing either of these:
1. Conversion functions based on byteaout/byteain.
2. Bytea to text escapes *only* null bytes, text to bytea treats only
"\0" as an escape sequence.
Or maybe both, with two pairs of conversion functions.
In any case, we have to decide whether these coercion functions should
be named after the types --- ie, should they be made invokable as
implicit coercions? I'm dubious that that's a good idea; if we do it
then all sorts of textual operations will suddenly be allowed for bytea
without any explicit conversion, which is likely to do more harm than
good. The reason for having a separate bytea type is exactly so that
you *can't* apply text ops to it without thinking.
regards, tom lane
