Re: bytea vs. pg_dump

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> OK, here is an updated patch. It has the setting as enum, completed
> documentation, and libpq support. I'll add it to the commit fest in the hope
> that someone else can look it over in detail.

I found that there is another issue that should be addressed, maybe not
by this patch but by a follow-on. While looking at Itagaki-san's patch
for making pg_dump --clean drop large objects, I noticed that pg_dump
is still relying on the deprecated function PQescapeBytea to dump the
contents of large objects when it is creating text output. This manages
not to fail for common cases, but there is at least one case we
overlooked: if you pg_dump with standard_conforming_strings turned on
into a custom (or probably tar) archive, and then use pg_restore to
generate a SQL script from that, the strings will be improperly escaped.

It strikes me that the best solution for this is to emit hex-coded
bytea instead of escaped bytea. While we could just hardcode that
into pg_dump, it would probably be better if libpq provided a function
along the lines of PQescapeByteaHex.

In some far future, maybe PQescapeBytea could be rescued from the depths
of deprecation by having it emit hex-coded output; but of course that
would fail against pre-8.5 servers, so it's a long way off.

In the nearer future, it would be possible and perhaps wise for
PQescapeByteaConn to adopt hex coding when it sees the connection is
to a server >= 8.5. It didn't look to me like the patch addressed
this either.

regards, tom lane