ljb wrote:
> bruce@momjian.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:
http://www.postgresql.org/docs/9.0/static/libpq-exec.html#LIBPQ-EXEC-ESCAPE-STRING
PQescapeByteaConn
...
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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +