Re: Bytea/Base64 encoders for libpq - interested?

> > I don't think adding a datatype just to provide base64 encoding is
> > a wise approach.  The overhead of a new datatype (in the sense of
> > providing operators/functions for it) will be much more than the
> > benefit.  I think providing encode/decode functions is sufficient...
> > and we have those already, don't we?
> >
> 
> 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.

> 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.

--  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,
Pennsylvania19026