> 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?
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?
-- Joe
