Re: Bytea string operator support

> Joe Conway writes:
>
> > 2. Added PQescapeBytea to fe-exec.c
>
> I'm not sure if we want to encode the peculiarities of particular data
> types into the client libraries. I could agree with adding a function
> that supplies a general-purpose encoding such as base64 (not necessarily
> preferred) which clients can use to feed data to the server. In the
> future we might want to support the SQL-standard input formats for binary
> data types, which would require yet another round of functions to be added
> to libpq.
>
> After all, bytea is utterly non-standard, and if we make API extensions we
> should consider them in the long run.

Bytea is pecular because you can't have the escaping done in the backend
because of the binary nature of bytea. I think there was an attempt to
merge this into the escaping of SQL queries but that can't work because
of the handling of nulls and the string possibly being four times bigger
than the original.

I agree this is type pollution into libpq but I don't see another option
except having the user code this stuff into their application. Maybe we
need some type-handling library in the future were we can put all this
stuff. Maybe we can add this to libpq now and create a separate library
when we need one.

Comments?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026