Skip site navigation (1) Skip section navigation (2)

Re: [GENERAL] Gripe: bytea_output default => data corruption

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: ljb <ljb9832(at)pobox(dot)com>
Cc: PostgreSQL-documentation <pgsql-docs(at)postgresql(dot)org>
Subject: Re: [GENERAL] Gripe: bytea_output default => data corruption
Date: 2010-10-21 23:42:14
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-docspgsql-general
ljb wrote:
> bruce(at)momjian(dot)us wrote:
> >...
> > Yes, we mentioned that setting in the release notes too:
> >...
> > While the "Incompatibilities" section mentions only the first paragraph,
> > this remention lower down has even more details.  Not sure what else you
> > wanted us to do.
> Here's how I would have written that first paragraph. My addition starts
> at "Libpq's PQunescapeBytea() function..."
> |  * Allow bytea values to be written in hex notation (Peter Eisentraut)
> |
> |   The server parameter bytea_output controls whether hex or
> | traditional format is used for bytea output. Libpq's PQescapeByteaConn()
> | function automatically uses the hex format when connected to PostgreSQL
> | 9.0 or newer servers. Libpq's PQunescapeBytea() function from version 9.0
> | and newer will properly decode both hex and traditional format. However,
> | in versions of Libpq older than 9.0, the PQunescapeByte() function can only
> | decode traditional format, and will corrupt bytea data received in hex
> | format without reporting an error. To avoid loss of data, you must either
> | upgrade all clients to 9.0.x, or set the server's bytea_output parameter
> | to 'escape'.
> Again: My complaint is that pre-9.0 libpq-based clients mis-decode the new
> default hex format bytea data without reporting an error, and this danger is
> insufficiently documented in the release notes.

[ Thread moved to docs.]

Yes, I don't believe we were aware of the silent error behavior;  I
certainly was not, and if I was, I would have mentioned it in the
release notes.

> Speaking of documentation, go read the 9.0.x reference manual sections for
> Libpq's PQescapeByteaConn() and PQunescapeBytea(). These descriptions of
> escaping and unescaping are incorrect for 9.0, which can add to any confusion.

Yikes, you are right!  I see:
	Certain byte values must be escaped (but all byte values can be escaped)
	when used as part of a bytea literal in an SQL statement. In general, to
-->	escape a byte, it is converted into the three digit octal number equal
	to the octet value, and preceded by usually two backslashes. The single
	quote (') and backslash (\) characters have special alternative escape
	sequences. See Section 8.4 for more information. PQescapeByteaConn
	performs this operation, escaping only the minimally required bytes. 

Can someone suggest some updated wording?  Thanks.

  Bruce Momjian  <bruce(at)momjian(dot)us>

  + It's impossible for everything to be true. +

In response to


pgsql-docs by date

Next:From: Vick KheraDate: 2010-10-22 16:19:33
Subject: Re: Gripe: bytea_output default => data corruption
Previous:From: ljbDate: 2010-10-21 23:12:40
Subject: Re: Gripe: bytea_output default => data corruption

pgsql-general by date

Next:From: zab08Date: 2010-10-22 00:24:02
Subject: compile error in libpq program
Previous:From: David KerrDate: 2010-10-21 23:38:31
Subject: Re: Generate a dynamic sequence within a query

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group