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.
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.
