Обсуждение: Re: [GENERAL] Gripe: bytea_output default => data corruption

Поиск
Список
Период
Сортировка

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

От
Bruce Momjian
Дата:
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. +

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

От
Tom Lane
Дата:
Bruce Momjian <bruce@momjian.us> writes:
> 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.

I think we should simply remove the description of *how* the escaping is
performed, and state only that the function produces a suitably escaped
literal string.  Anything else is not future-proof, and could someday
break the way this wording did.

            regards, tom lane

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

От
ljb
Дата:
tgl@sss.pgh.pa.us wrote:
> I think we should simply remove the description of *how* the escaping is
> performed, and state only that the function produces a suitably escaped
> literal string.  Anything else is not future-proof, and could someday
> break the way this wording did.

Perhaps it would be best to remove escaping details here. But the
description of PQescapeBytea() might need to be rewritten, too. Without
describing exactly what PQescapeByteaConn() does, it is hard to understand
what PQescapeBytea() does not do, and why it therefore "might give the
wrong results".

I think the actual function behavior should be documented somewhere. Even
though it might change again.