> > It might be nice to have a PQbyteaEscape or some such function available
in
> > the libpq client library so that arbitrary binary could be escaped on
the
> > client side and used in a sql statement. I actually wrote this already
as an
> > addition to the PHP PostgreSQL extension, but it would make more sense,
now
> > that I think about it, for it to be in libpq and called from PHP (or
> > whatever). Comments?
>
> Good idea. I will commit the non-bytea escape in a day and you can base
> a bytea one on that. You will have to pass in the length of the field
> because of course it is not null terminated.
OK.
>
> > On a related note, are there any other bytea functions we should have in
the
> > backend before freezing for 7.2? I was thinking it would be nice to have
a
> > way to cast bytea into text and vice-versa, so that the normal text
> > functions could be used for things like LIKE and concatenation. Any
interest
> > in this? If so, any guidance WRT how it should be implemented?
>
> I can't see why you can't do that. The only problem is passing a \0
> (null byte) back to the client.
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.
Any comments or concerns?
-- Joe