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

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

From
Bruce Momjian
Date:
ljb wrote:
> 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.

Based on this report, I have created the attached documentation patch
which clarifies the libpq behavior for escaping bytea.  I am planning to
backpatch this to 9.0 as well.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index 7b70970..26f5140 100644
*** a/doc/src/sgml/libpq.sgml
--- b/doc/src/sgml/libpq.sgml
*************** unsigned char *PQescapeByteaConn(PGconn
*** 3419,3434 ****
        </para>

        <para>
!        Certain byte values <emphasis>must</emphasis> be escaped (but all
!        byte values <emphasis>can</emphasis> be escaped) when used as part
!        of a <type>bytea</type> literal in an <acronym>SQL</acronym>
!        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 (<literal>'</>) and backslash
!        (<literal>\</>) characters have special alternative escape
!        sequences. See <xref linkend="datatype-binary"> for more
!        information. <function>PQescapeByteaConn</function> performs this
!        operation, escaping only the minimally required bytes.
        </para>

        <para>
--- 3419,3429 ----
        </para>

        <para>
!        Certain byte values must be escaped when used as part of a
!        <type>bytea</type> literal in an <acronym>SQL</acronym> statement.
!        <function>PQescapeByteaConn</function> escapes such bytes using
!        either hex encoding or backslash escaping.  See <xref
!        linkend="datatype-binary"> for more information.
        </para>

        <para>
*************** unsigned char *PQescapeBytea(const unsig
*** 3486,3495 ****
         The only difference from <function>PQescapeByteaConn</> is that
         <function>PQescapeBytea</> does not take a <structname>PGconn</>
         parameter.  Because of this, it cannot adjust its behavior
!        depending on the connection properties (in particular, whether
!        standard-conforming strings are enabled) and therefore
!        <emphasis>it might give the wrong results</>.  Also, it has no
!        way to return an error message on failure.
        </para>

        <para>
--- 3481,3490 ----
         The only difference from <function>PQescapeByteaConn</> is that
         <function>PQescapeBytea</> does not take a <structname>PGconn</>
         parameter.  Because of this, it cannot adjust its behavior
!        depending on the connection properties (e.g.
!        <literal>standard_conforming_strings</>, <literal>bytea_output</a>)
!        and therefore <emphasis>might give the wrong results</>.  Also,
!        it has no way to return an error message on failure.
        </para>

        <para>
diff --git a/doc/src/sgml/release-9.0.sgml b/doc/src/sgml/release-9.0.sgml
index 2288f1b..c43f142 100644
*** a/doc/src/sgml/release-9.0.sgml
--- b/doc/src/sgml/release-9.0.sgml
***************
*** 2342,2348 ****
        whether hex or traditional format is used for <type>bytea</>
        output.  Libpq's <function>PQescapeByteaConn()</> function automatically
        uses the hex format when connected to <productname>PostgreSQL</> 9.0
!       or newer servers.
       </para>

       <para>
--- 2342,2349 ----
        whether hex or traditional format is used for <type>bytea</>
        output.  Libpq's <function>PQescapeByteaConn()</> function automatically
        uses the hex format when connected to <productname>PostgreSQL</> 9.0
!       or newer servers.  However, pre-9.0 libpq versions will not
!       correctly process hex format from newer servers.
       </para>

       <para>
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index 7b70970..26f5140 100644
*** a/doc/src/sgml/libpq.sgml
--- b/doc/src/sgml/libpq.sgml
*************** unsigned char *PQescapeByteaConn(PGconn
*** 3419,3434 ****
        </para>

        <para>
!        Certain byte values <emphasis>must</emphasis> be escaped (but all
!        byte values <emphasis>can</emphasis> be escaped) when used as part
!        of a <type>bytea</type> literal in an <acronym>SQL</acronym>
!        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 (<literal>'</>) and backslash
!        (<literal>\</>) characters have special alternative escape
!        sequences. See <xref linkend="datatype-binary"> for more
!        information. <function>PQescapeByteaConn</function> performs this
!        operation, escaping only the minimally required bytes.
        </para>

        <para>
--- 3419,3429 ----
        </para>

        <para>
!        Certain byte values must be escaped when used as part of a
!        <type>bytea</type> literal in an <acronym>SQL</acronym> statement.
!        <function>PQescapeByteaConn</function> escapes such bytes using
!        either hex encoding or backslash escaping.  See <xref
!        linkend="datatype-binary"> for more information.
        </para>

        <para>
*************** unsigned char *PQescapeBytea(const unsig
*** 3486,3495 ****
         The only difference from <function>PQescapeByteaConn</> is that
         <function>PQescapeBytea</> does not take a <structname>PGconn</>
         parameter.  Because of this, it cannot adjust its behavior
!        depending on the connection properties (in particular, whether
!        standard-conforming strings are enabled) and therefore
!        <emphasis>it might give the wrong results</>.  Also, it has no
!        way to return an error message on failure.
        </para>

        <para>
--- 3481,3490 ----
         The only difference from <function>PQescapeByteaConn</> is that
         <function>PQescapeBytea</> does not take a <structname>PGconn</>
         parameter.  Because of this, it cannot adjust its behavior
!        depending on the connection properties (e.g.
!        <literal>standard_conforming_strings</>, <literal>bytea_output</a>)
!        and therefore <emphasis>might give the wrong results</>.  Also,
!        it has no way to return an error message on failure.
        </para>

        <para>

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

From
Bruce Momjian
Date:
Bruce Momjian wrote:
> ljb wrote:
> > 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.
>
> Based on this report, I have created the attached documentation patch
> which clarifies the libpq behavior for escaping bytea.  I am planning to
> backpatch this to 9.0 as well.

My aplogies on the double-attachment.  I am now attaching the right
verison.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index 7b70970..26f5140 100644
*** a/doc/src/sgml/libpq.sgml
--- b/doc/src/sgml/libpq.sgml
*************** unsigned char *PQescapeByteaConn(PGconn
*** 3419,3434 ****
        </para>

        <para>
!        Certain byte values <emphasis>must</emphasis> be escaped (but all
!        byte values <emphasis>can</emphasis> be escaped) when used as part
!        of a <type>bytea</type> literal in an <acronym>SQL</acronym>
!        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 (<literal>'</>) and backslash
!        (<literal>\</>) characters have special alternative escape
!        sequences. See <xref linkend="datatype-binary"> for more
!        information. <function>PQescapeByteaConn</function> performs this
!        operation, escaping only the minimally required bytes.
        </para>

        <para>
--- 3419,3429 ----
        </para>

        <para>
!        Certain byte values must be escaped when used as part of a
!        <type>bytea</type> literal in an <acronym>SQL</acronym> statement.
!        <function>PQescapeByteaConn</function> escapes such bytes using
!        either hex encoding or backslash escaping.  See <xref
!        linkend="datatype-binary"> for more information.
        </para>

        <para>
*************** unsigned char *PQescapeBytea(const unsig
*** 3486,3495 ****
         The only difference from <function>PQescapeByteaConn</> is that
         <function>PQescapeBytea</> does not take a <structname>PGconn</>
         parameter.  Because of this, it cannot adjust its behavior
!        depending on the connection properties (in particular, whether
!        standard-conforming strings are enabled) and therefore
!        <emphasis>it might give the wrong results</>.  Also, it has no
!        way to return an error message on failure.
        </para>

        <para>
--- 3481,3490 ----
         The only difference from <function>PQescapeByteaConn</> is that
         <function>PQescapeBytea</> does not take a <structname>PGconn</>
         parameter.  Because of this, it cannot adjust its behavior
!        depending on the connection properties (e.g.
!        <literal>standard_conforming_strings</>, <literal>bytea_output</a>)
!        and therefore <emphasis>might give the wrong results</>.  Also,
!        it has no way to return an error message on failure.
        </para>

        <para>
diff --git a/doc/src/sgml/release-9.0.sgml b/doc/src/sgml/release-9.0.sgml
index 2288f1b..c43f142 100644
*** a/doc/src/sgml/release-9.0.sgml
--- b/doc/src/sgml/release-9.0.sgml
***************
*** 2342,2348 ****
        whether hex or traditional format is used for <type>bytea</>
        output.  Libpq's <function>PQescapeByteaConn()</> function automatically
        uses the hex format when connected to <productname>PostgreSQL</> 9.0
!       or newer servers.
       </para>

       <para>
--- 2342,2349 ----
        whether hex or traditional format is used for <type>bytea</>
        output.  Libpq's <function>PQescapeByteaConn()</> function automatically
        uses the hex format when connected to <productname>PostgreSQL</> 9.0
!       or newer servers.  However, pre-9.0 libpq versions will not
!       correctly process hex format from newer servers.
       </para>

       <para>

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

From
ljb
Date:
bruce@momjian.us wrote:
>...
>> Based on this report, I have created the attached documentation patch
>> which clarifies the libpq behavior for escaping bytea.  I am planning to
>> backpatch this to 9.0 as well.

This change says PQescapeBytea is unable to adjust its behavior based on
bytea_output, implying that PQescapeByteaConn does adjust its behavior
based on byte_output. Wrong! Neither one knows or cares about the bytea_output
parameter, which is solely for the backend to tell it how to present bytea
data to the front-end. Not for the front-ends at all.

(See why we need this behavior documented?)

Non-use of 'standard_conforming_strings' is also wrong, in the current
(pre-patched) docs. PQescapeBytea does adjust its behavior for
standard_conforming_strings, but only for the single-connection case. See
similar text for PQescapeString.

Regarding the first paragraph changed, it seems off to me.  "PQescapeByteConn
escapes such bytes using either hex encoding..." tells me that when hex
encoding is used, PQescapeByte encodes only bytes that need escaping. Not
true - hex encoding encodes (not escapes) every byte.

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

From
Bruce Momjian
Date:
ljb wrote:
> bruce@momjian.us wrote:
> >...
> >> Based on this report, I have created the attached documentation patch
> >> which clarifies the libpq behavior for escaping bytea.  I am planning to
> >> backpatch this to 9.0 as well.
>
> This change says PQescapeBytea is unable to adjust its behavior based on
> bytea_output, implying that PQescapeByteaConn does adjust its behavior
> based on byte_output. Wrong! Neither one knows or cares about the bytea_output
> parameter, which is solely for the backend to tell it how to present bytea
> data to the front-end. Not for the front-ends at all.

Good point, sorry.

> (See why we need this behavior documented?)

Yep!

> Non-use of 'standard_conforming_strings' is also wrong, in the current
> (pre-patched) docs. PQescapeBytea does adjust its behavior for
> standard_conforming_strings, but only for the single-connection case. See
> similar text for PQescapeString.

Yep.

> Regarding the first paragraph changed, it seems off to me.  "PQescapeByteConn
> escapes such bytes using either hex encoding..." tells me that when hex
> encoding is used, PQescapeByte encodes only bytes that need escaping. Not
> true - hex encoding encodes (not escapes) every byte.

OK, great feedback.  I made the adjustments you suggested and tried to
pattern it after PQescapeStringConn, with adjustments where appropriate.

Here is an updated patch, again to be backpatched to 9.0.  There were
obviously big mistakes in libpq docs and I am embarrassed I waited so
long to fix this;  my apologies.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index e78d708..56b72a7 100644
*** a/doc/src/sgml/libpq.sgml
--- b/doc/src/sgml/libpq.sgml
*************** size_t PQescapeStringConn(PGconn *conn,
*** 3371,3385 ****

       <listitem>
       <para>
  <synopsis>
  size_t PQescapeString (char *to, const char *from, size_t length);
  </synopsis>
       </para>

       <para>
!       <function>PQescapeString</> is an older, deprecated version of
!       <function>PQescapeStringConn</>; the difference is that it does
!       not take <parameter>conn</> or <parameter>error</> parameters.
        Because of this, it cannot adjust its behavior depending on the
        connection properties (such as character encoding) and therefore
        <emphasis>it might give the wrong results</>.  Also, it has no way
--- 3371,3387 ----

       <listitem>
       <para>
+        <function>PQescapeString</> is an older, deprecated version of
+        <function>PQescapeStringConn</>.
  <synopsis>
  size_t PQescapeString (char *to, const char *from, size_t length);
  </synopsis>
       </para>

       <para>
!       The only difference from <function>PQescapeStringConn</> is that
!       <function>PQescapeString</> does not take a <structname>PGconn</>
!       or <parameter>error</> parameters.
        Because of this, it cannot adjust its behavior depending on the
        connection properties (such as character encoding) and therefore
        <emphasis>it might give the wrong results</>.  Also, it has no way
*************** size_t PQescapeString (char *to, const c
*** 3387,3393 ****
       </para>

       <para>
!       <function>PQescapeString</> can be used safely in single-threaded
        client programs that work with only one <productname>PostgreSQL</>
        connection at a time (in this case it can find out what it needs to
        know <quote>behind the scenes</>).  In other contexts it is a security
--- 3389,3395 ----
       </para>

       <para>
!       <function>PQescapeString</> can be used safely in
        client programs that work with only one <productname>PostgreSQL</>
        connection at a time (in this case it can find out what it needs to
        know <quote>behind the scenes</>).  In other contexts it is a security
*************** unsigned char *PQescapeByteaConn(PGconn
*** 3419,3434 ****
        </para>

        <para>
!        Certain byte values <emphasis>must</emphasis> be escaped (but all
!        byte values <emphasis>can</emphasis> be escaped) when used as part
!        of a <type>bytea</type> literal in an <acronym>SQL</acronym>
!        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 (<literal>'</>) and backslash
!        (<literal>\</>) characters have special alternative escape
!        sequences. See <xref linkend="datatype-binary"> for more
!        information. <function>PQescapeByteaConn</function> performs this
!        operation, escaping only the minimally required bytes.
        </para>

        <para>
--- 3421,3431 ----
        </para>

        <para>
!        Certain byte values must be escaped when used as part of a
!        <type>bytea</type> literal in an <acronym>SQL</acronym> statement.
!        <function>PQescapeByteaConn</function> escapes bytes using
!        either hex encoding or backslash escaping.  See <xref
!        linkend="datatype-binary"> for more information.
        </para>

        <para>
*************** unsigned char *PQescapeBytea(const unsig
*** 3485,3504 ****
        <para>
         The only difference from <function>PQescapeByteaConn</> is that
         <function>PQescapeBytea</> does not take a <structname>PGconn</>
!        parameter.  Because of this, it cannot adjust its behavior
!        depending on the connection properties (in particular, whether
!        standard-conforming strings are enabled) and therefore
!        <emphasis>it might give the wrong results</>.  Also, it has no
!        way to return an error message on failure.
!       </para>
!
!       <para>
!        <function>PQescapeBytea</> can be used safely in single-threaded
!        client programs that work with only one <productname>PostgreSQL</>
!        connection at a time (in this case it can find out what it needs
!        to know <quote>behind the scenes</>).  In other contexts it is
!        a security hazard and should be avoided in favor of
!        <function>PQescapeByteaConn</>.
        </para>
       </listitem>
      </varlistentry>
--- 3482,3495 ----
        <para>
         The only difference from <function>PQescapeByteaConn</> is that
         <function>PQescapeBytea</> does not take a <structname>PGconn</>
!        or <parameter>error</> parameters.  Because of this,
!        <function>PQescapeBytea</> can only be used safely in client
!        programs that use a single <productname>PostgreSQL</> connection
!        at a time (in this case it can find out what it needs to know
!        <quote>behind the scenes</>).  It <emphasis>might give the
!        wrong results</> if used in programs that use multiple database
!        connections (use <function>PQescapeByteaConn</> in such cases).
!        Also, it has no way to report error conditions.
        </para>
       </listitem>
      </varlistentry>
diff --git a/doc/src/sgml/release-9.0.sgml b/doc/src/sgml/release-9.0.sgml
index 2288f1b..c43f142 100644
*** a/doc/src/sgml/release-9.0.sgml
--- b/doc/src/sgml/release-9.0.sgml
***************
*** 2342,2348 ****
        whether hex or traditional format is used for <type>bytea</>
        output.  Libpq's <function>PQescapeByteaConn()</> function automatically
        uses the hex format when connected to <productname>PostgreSQL</> 9.0
!       or newer servers.
       </para>

       <para>
--- 2342,2349 ----
        whether hex or traditional format is used for <type>bytea</>
        output.  Libpq's <function>PQescapeByteaConn()</> function automatically
        uses the hex format when connected to <productname>PostgreSQL</> 9.0
!       or newer servers.  However, pre-9.0 libpq versions will not
!       correctly process hex format from newer servers.
       </para>

       <para>

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

From
ljb
Date:
bruce@momjian.us wrote:
> Here is an updated patch, again to be backpatched to 9.0.

Getting better.

In change block 1, after PQescapeString synopsis:
Change: "does not take a Pgconn or error parameters"
    to: "does not take Pgconn or error parameters"

In change block 4, PQescapeBytea, I don't like the change.
This: "is that PQescapeBytea does not take a PGconn or error parameters"
is wrong. PQescapeByteaConn does not take an 'error' parameter either.
Also "no way to report error conditions" is wrong. It returns NULL on an
error; it just cannot return a specific error message. (Which is OK because
there is only one, unlikely error: out of memory.)

Reading the before/after text here, I don't see anything that needs
changing except for dropping the reference to single-threaded (same as for
PQescapeString). I suggest going back to the original text and just
changing:
From: "can be used safely in single-threaded client programs that work with
       only one"
  to: "can only be used safely in client programs that use a single"

(Sorry for the trouble. I should have fully commented on the first one, but
I find it hard to see the changes with these "git" diffs of SGML.)

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

From
Bruce Momjian
Date:
ljb wrote:
> bruce@momjian.us wrote:
> > Here is an updated patch, again to be backpatched to 9.0.
>
> Getting better.
>
> In change block 1, after PQescapeString synopsis:
> Change: "does not take a Pgconn or error parameters"
>     to: "does not take Pgconn or error parameters"
>
> In change block 4, PQescapeBytea, I don't like the change.
> This: "is that PQescapeBytea does not take a PGconn or error parameters"
> is wrong. PQescapeByteaConn does not take an 'error' parameter either.
> Also "no way to report error conditions" is wrong. It returns NULL on an
> error; it just cannot return a specific error message. (Which is OK because
> there is only one, unlikely error: out of memory.)
>
> Reading the before/after text here, I don't see anything that needs
> changing except for dropping the reference to single-threaded (same as for
> PQescapeString). I suggest going back to the original text and just
> changing:
> From: "can be used safely in single-threaded client programs that work with
>        only one"
>   to: "can only be used safely in client programs that use a single"
>
> (Sorry for the trouble. I should have fully commented on the first one, but
> I find it hard to see the changes with these "git" diffs of SGML.)

OK, updated version attached.  I keep most of the new patch for the
PQescapeBytea docs rather than use most of the original so it would
match text for other escape functions.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index e78d708..b2ab555 100644
*** a/doc/src/sgml/libpq.sgml
--- b/doc/src/sgml/libpq.sgml
*************** size_t PQescapeStringConn(PGconn *conn,
*** 3371,3385 ****

       <listitem>
       <para>
  <synopsis>
  size_t PQescapeString (char *to, const char *from, size_t length);
  </synopsis>
       </para>

       <para>
!       <function>PQescapeString</> is an older, deprecated version of
!       <function>PQescapeStringConn</>; the difference is that it does
!       not take <parameter>conn</> or <parameter>error</> parameters.
        Because of this, it cannot adjust its behavior depending on the
        connection properties (such as character encoding) and therefore
        <emphasis>it might give the wrong results</>.  Also, it has no way
--- 3371,3387 ----

       <listitem>
       <para>
+        <function>PQescapeString</> is an older, deprecated version of
+        <function>PQescapeStringConn</>.
  <synopsis>
  size_t PQescapeString (char *to, const char *from, size_t length);
  </synopsis>
       </para>

       <para>
!       The only difference from <function>PQescapeStringConn</> is that
!       <function>PQescapeString</> does not take <structname>PGconn</>
!       or <parameter>error</> parameters.
        Because of this, it cannot adjust its behavior depending on the
        connection properties (such as character encoding) and therefore
        <emphasis>it might give the wrong results</>.  Also, it has no way
*************** size_t PQescapeString (char *to, const c
*** 3387,3393 ****
       </para>

       <para>
!       <function>PQescapeString</> can be used safely in single-threaded
        client programs that work with only one <productname>PostgreSQL</>
        connection at a time (in this case it can find out what it needs to
        know <quote>behind the scenes</>).  In other contexts it is a security
--- 3389,3395 ----
       </para>

       <para>
!       <function>PQescapeString</> can be used safely in
        client programs that work with only one <productname>PostgreSQL</>
        connection at a time (in this case it can find out what it needs to
        know <quote>behind the scenes</>).  In other contexts it is a security
*************** unsigned char *PQescapeByteaConn(PGconn
*** 3419,3434 ****
        </para>

        <para>
!        Certain byte values <emphasis>must</emphasis> be escaped (but all
!        byte values <emphasis>can</emphasis> be escaped) when used as part
!        of a <type>bytea</type> literal in an <acronym>SQL</acronym>
!        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 (<literal>'</>) and backslash
!        (<literal>\</>) characters have special alternative escape
!        sequences. See <xref linkend="datatype-binary"> for more
!        information. <function>PQescapeByteaConn</function> performs this
!        operation, escaping only the minimally required bytes.
        </para>

        <para>
--- 3421,3431 ----
        </para>

        <para>
!        Certain byte values must be escaped when used as part of a
!        <type>bytea</type> literal in an <acronym>SQL</acronym> statement.
!        <function>PQescapeByteaConn</function> escapes bytes using
!        either hex encoding or backslash escaping.  See <xref
!        linkend="datatype-binary"> for more information.
        </para>

        <para>
*************** unsigned char *PQescapeBytea(const unsig
*** 3485,3504 ****
        <para>
         The only difference from <function>PQescapeByteaConn</> is that
         <function>PQescapeBytea</> does not take a <structname>PGconn</>
!        parameter.  Because of this, it cannot adjust its behavior
!        depending on the connection properties (in particular, whether
!        standard-conforming strings are enabled) and therefore
!        <emphasis>it might give the wrong results</>.  Also, it has no
!        way to return an error message on failure.
!       </para>
!
!       <para>
!        <function>PQescapeBytea</> can be used safely in single-threaded
!        client programs that work with only one <productname>PostgreSQL</>
!        connection at a time (in this case it can find out what it needs
!        to know <quote>behind the scenes</>).  In other contexts it is
!        a security hazard and should be avoided in favor of
!        <function>PQescapeByteaConn</>.
        </para>
       </listitem>
      </varlistentry>
--- 3482,3494 ----
        <para>
         The only difference from <function>PQescapeByteaConn</> is that
         <function>PQescapeBytea</> does not take a <structname>PGconn</>
!        parameter.  Because of this, <function>PQescapeBytea</> can
!        only be used safely in client programs that use a single
!        <productname>PostgreSQL</> connection at a time (in this case
!        it can find out what it needs to know <quote>behind the
!        scenes</>).  It <emphasis>might give the wrong results</> if
!        used in programs that use multiple database connections (use
!        <function>PQescapeByteaConn</> in such cases).
        </para>
       </listitem>
      </varlistentry>
diff --git a/doc/src/sgml/release-9.0.sgml b/doc/src/sgml/release-9.0.sgml
index 2288f1b..c43f142 100644
*** a/doc/src/sgml/release-9.0.sgml
--- b/doc/src/sgml/release-9.0.sgml
***************
*** 2342,2348 ****
        whether hex or traditional format is used for <type>bytea</>
        output.  Libpq's <function>PQescapeByteaConn()</> function automatically
        uses the hex format when connected to <productname>PostgreSQL</> 9.0
!       or newer servers.
       </para>

       <para>
--- 2342,2349 ----
        whether hex or traditional format is used for <type>bytea</>
        output.  Libpq's <function>PQescapeByteaConn()</> function automatically
        uses the hex format when connected to <productname>PostgreSQL</> 9.0
!       or newer servers.  However, pre-9.0 libpq versions will not
!       correctly process hex format from newer servers.
       </para>

       <para>

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

From
ljb
Date:
bruce@momjian.us wrote:
>...
> OK, updated version attached.  I keep most of the new patch for the
> PQescapeBytea docs rather than use most of the original so it would
> match text for other escape functions.

Looks good to me.

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

From
Bruce Momjian
Date:
ljb wrote:
> bruce@momjian.us wrote:
> >...
> > OK, updated version attached.  I keep most of the new patch for the
> > PQescapeBytea docs rather than use most of the original so it would
> > match text for other escape functions.
>
> Looks good to me.

Thanks for the reviews.  Applied and backpatched to 9.0 (once git comes
back online).

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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