> > 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
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
