> >
> > > 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?
That was the main reason I wanted to see the bytea escape function in the
PostgreSQL client library. Without it, every user needs to code something
that performs this same functionality into their own app if they want to do
something like: insert into foo(f1) values ('binary stuff');
Someone has mentioned that the Perl DBI module for PostgreSQL can
already do this, but that doesn't help anyone writing in C or PHP
(as two examples).
Certainly if there is a SQL-standard, it would be better to support it. I
scanned through SQL99, but didn't spot anything on SQL-standard input
formats for binary. Peter, can you point me in the right direction?
-- Joe
