pg.ddx.io pgsql-docs@postgresql.org mailing list archive
help / color / mirror / Atom feedGripe: bytea_output default => data corruption
21+ messages / 7 participants
[nested] [flat]
* Gripe: bytea_output default => data corruption
@ 2010-10-13 00:37 ljb <ljb9832@pobox.com>
0 siblings, 1 reply; 21+ messages in thread
From: ljb @ 2010-10-13 00:37 UTC (permalink / raw)
To: pgsql-general@postgresql.org
Defaulting bytea output from the backend to use hex mode encoding, which is
incompatible with pre-9.0 interfaces, wasn't a friendly thing to do. The
default should have been escape mode. Or else you needed a big warning in
HISTORY that we must either change bytea_output, or upgrade all clients
before servers. Because using a 9.0 server with a 8.x libpq-based client
results in undetected data corruption when selecting BYTEA objects.
By default, the 9.0 server encodes a bytea using hex mode, but an 8.x
libpq-based client will decode that using escape mode, with no error detected
on either end. For example, start with "A", encode to "\x40" decode to "x40".
There are good reasons to break backward compatibility, like security or
standards compliance, but not performance. Please think twice next time you
consider breaking stuff just because you think the new way should be faster.
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: Gripe: bytea_output default => data corruption
@ 2010-10-13 07:45 Raymond O'Donnell <rod@iol.ie>
parent: ljb <ljb9832@pobox.com>
0 siblings, 2 replies; 21+ messages in thread
From: Raymond O'Donnell @ 2010-10-13 07:45 UTC (permalink / raw)
To: ljb <ljb9832@pobox.com>; +Cc: pgsql-general@postgresql.org
On 13/10/2010 01:37, ljb wrote:
> Defaulting bytea output from the backend to use hex mode encoding, which is
> incompatible with pre-9.0 interfaces, wasn't a friendly thing to do. The
> default should have been escape mode. Or else you needed a big warning in
> HISTORY that we must either change bytea_output, or upgrade all clients
> before servers. Because using a 9.0 server with a 8.x libpq-based client
> results in undetected data corruption when selecting BYTEA objects.
>
> By default, the 9.0 server encodes a bytea using hex mode, but an 8.x
> libpq-based client will decode that using escape mode, with no error detected
> on either end. For example, start with "A", encode to "\x40" decode to "x40".
>
> There are good reasons to break backward compatibility, like security or
> standards compliance, but not performance. Please think twice next time you
> consider breaking stuff just because you think the new way should be faster.
In fairness, it *is* flagged in the release note - it's the first item
under "data types" in the list of incompatibilities.
Ray.
--
Raymond O'Donnell :: Galway :: Ireland
rod@iol.ie
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: Gripe: bytea_output default => data corruption
@ 2010-10-13 12:48 Dmitriy Igrishin <dmitigr@gmail.com>
parent: Raymond O'Donnell <rod@iol.ie>
1 sibling, 0 replies; 21+ messages in thread
From: Dmitriy Igrishin @ 2010-10-13 12:48 UTC (permalink / raw)
To: rod@iol.ie; +Cc: ljb <ljb9832@pobox.com>; pgsql-general@postgresql.org
Hey all,
And it is 9.0, i.e another major version. IMO the higher major versions not
necessarily must be 100% backward compatible. So, think twice next time
you update the major version.
2010/10/13 Raymond O'Donnell <rod@iol.ie>
> On 13/10/2010 01:37, ljb wrote:
>
>> Defaulting bytea output from the backend to use hex mode encoding, which
>> is
>> incompatible with pre-9.0 interfaces, wasn't a friendly thing to do. The
>> default should have been escape mode. Or else you needed a big warning in
>> HISTORY that we must either change bytea_output, or upgrade all clients
>> before servers. Because using a 9.0 server with a 8.x libpq-based client
>> results in undetected data corruption when selecting BYTEA objects.
>>
>> By default, the 9.0 server encodes a bytea using hex mode, but an 8.x
>> libpq-based client will decode that using escape mode, with no error
>> detected
>> on either end. For example, start with "A", encode to "\x40" decode to
>> "x40".
>>
>> There are good reasons to break backward compatibility, like security or
>> standards compliance, but not performance. Please think twice next time
>> you
>> consider breaking stuff just because you think the new way should be
>> faster.
>>
>
> In fairness, it *is* flagged in the release note - it's the first item
> under "data types" in the list of incompatibilities.
>
> Ray.
>
> --
> Raymond O'Donnell :: Galway :: Ireland
> rod@iol.ie
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>
--
// Dmitriy.
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: Gripe: bytea_output default => data corruption
@ 2010-10-13 21:03 ljb <ljb9832@pobox.com>
parent: Raymond O'Donnell <rod@iol.ie>
1 sibling, 2 replies; 21+ messages in thread
From: ljb @ 2010-10-13 21:03 UTC (permalink / raw)
To: pgsql-general@postgresql.org
rod@iol.ie wrote:
>...
> In fairness, it *is* flagged in the release note - it's the first item
> under "data types" in the list of incompatibilities.
Quote:
"bytea output now appears in hex format by default (Peter Eisentraut)
The server parameter bytea_output can be used to select the
traditional output format if needed for compatibility."
This is inadequate, because it fails to warn that pre-9.0 clients will
decode the data incorrectly without reporting an error.
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: Gripe: bytea_output default => data corruption
@ 2010-10-14 09:15 Raymond O'Donnell <rod@iol.ie>
parent: ljb <ljb9832@pobox.com>
1 sibling, 0 replies; 21+ messages in thread
From: Raymond O'Donnell @ 2010-10-14 09:15 UTC (permalink / raw)
To: ljb <ljb9832@pobox.com>; +Cc: pgsql-general@postgresql.org
On 13/10/2010 22:03, ljb wrote:
> rod@iol.ie wrote:
>> ...
>> In fairness, it *is* flagged in the release note - it's the first item
>> under "data types" in the list of incompatibilities.
>
> Quote:
> "bytea output now appears in hex format by default (Peter Eisentraut)
> The server parameter bytea_output can be used to select the
> traditional output format if needed for compatibility."
>
> This is inadequate, because it fails to warn that pre-9.0 clients will
> decode the data incorrectly without reporting an error.
I thought myself that the word "incompatibility" was fairly
self-explanatory... :-)
Ray.
--
Raymond O'Donnell :: Galway :: Ireland
rod@iol.ie
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: Gripe: bytea_output default => data corruption
@ 2010-10-14 09:19 Rajesh Kumar Mallah <mallah.rajesh@gmail.com>
parent: ljb <ljb9832@pobox.com>
1 sibling, 1 reply; 21+ messages in thread
From: Rajesh Kumar Mallah @ 2010-10-14 09:19 UTC (permalink / raw)
To: ljb <ljb9832@pobox.com>; +Cc: pgsql-general@postgresql.org
Dear Griper!,
fortunately someone showed a easy 'fix'
ALTER DATABASE foo SET bytea_output='escape' ;
Regds
Rajesh Kumar Mallah.
On Wed, Oct 13, 2010 at 5:03 PM, ljb <ljb9832@pobox.com> wrote:
> rod@iol.ie wrote:
>>...
>> In fairness, it *is* flagged in the release note - it's the first item
>> under "data types" in the list of incompatibilities.
>
> Quote:
> "bytea output now appears in hex format by default (Peter Eisentraut)
> The server parameter bytea_output can be used to select the
> traditional output format if needed for compatibility."
>
> This is inadequate, because it fails to warn that pre-9.0 clients will
> decode the data incorrectly without reporting an error.
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: Gripe: bytea_output default => data corruption
@ 2010-10-21 21:29 Bruce Momjian <bruce@momjian.us>
parent: Rajesh Kumar Mallah <mallah.rajesh@gmail.com>
0 siblings, 1 reply; 21+ messages in thread
From: Bruce Momjian @ 2010-10-21 21:29 UTC (permalink / raw)
To: Rajesh Kumar Mallah <mallah.rajesh@gmail.com>; +Cc: ljb <ljb9832@pobox.com>; pgsql-general@postgresql.org
Rajesh Kumar Mallah wrote:
> Dear Griper!,
>
> fortunately someone showed a easy 'fix'
>
> ALTER DATABASE foo SET bytea_output='escape' ;
Yes, we mentioned that setting in the release notes too:
E.2.3.5. Data Types
*
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.
The new hex format will be directly compatible with more
applications that use binary data, allowing them to store and retrieve
it without extra conversion. It is also significantly faster to read and
write than the traditional format.
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.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: Gripe: bytea_output default => data corruption
@ 2010-10-21 23:12 ljb <ljb9832@pobox.com>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 2 replies; 21+ messages in thread
From: ljb @ 2010-10-21 23:12 UTC (permalink / raw)
To: pgsql-general@postgresql.org
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.
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: [GENERAL] Gripe: bytea_output default => data corruption
@ 2010-10-21 23:42 Bruce Momjian <bruce@momjian.us>
parent: ljb <ljb9832@pobox.com>
1 sibling, 1 reply; 21+ messages in thread
From: Bruce Momjian @ 2010-10-21 23:42 UTC (permalink / raw)
To: ljb <ljb9832@pobox.com>; +Cc: pgsql-docs
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. +
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: Gripe: bytea_output default => data corruption
@ 2010-10-22 16:19 Vick Khera <vivek@khera.org>
parent: ljb <ljb9832@pobox.com>
1 sibling, 1 reply; 21+ messages in thread
From: Vick Khera @ 2010-10-22 16:19 UTC (permalink / raw)
To: pgsql-general <pgsql-general@postgresql.org>
On Thu, Oct 21, 2010 at 7:12 PM, ljb <ljb9832@pobox.com> wrote:
> 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.
>
I had some hoops thru which I had to jump to make our app compatible with
both 8.x and 9.x so we could safely migrate our servers without having to
coordinate a code push. It wasn't that bad, but part of the problem is that
the DBD::Pg driver does not understand the new format... but it does
unescape the "\x" marker for me to a simple "x", since that follows the
traditional un-escaping rules for values returned from Pg. I don't like
overriding defaults in the DB settings unless I *really* have to.
So my code now looks something like this:
if (substr($value,2,100) =~ m/^[0-9a-f]+$/) {
# hex coding of bytea from Postgres 9.0+
$self->log_debug('bytea hex decode');
# remove the leading \x. DBD::Pg descapes \x to x, so just remove x
$value =~ s/^[^0-9a-f]+//;
$value = pack('H*',$value); # convert hex to bytes
} else {
$self->log_debug('bytea escape decoded');
# Postgres < 9.0 encode auto handled by DBD::Pg
}
Unfortunately, Greg is saying that he has no time right now to release an
updated DBD::Pg despite the fact that the code is written and merged into
the development source tree... so it may be a while before perl people are
happy. Luckily my above code will work even when DBD::Pg learns to do
auto-escaping of bytea new format.
At least the current $dbh->quote() method still seems to create acceptable
escaping for postgres 9.0 when you tell it you have a bytea field type.
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: Gripe: bytea_output default => data corruption
@ 2010-10-22 22:06 ljb <ljb9832@pobox.com>
parent: Vick Khera <vivek@khera.org>
0 siblings, 0 replies; 21+ messages in thread
From: ljb @ 2010-10-22 22:06 UTC (permalink / raw)
To: pgsql-general@postgresql.org
vivek@khera.org wrote:
>...
> I had some hoops thru which I had to jump to make our app compatible with
> both 8.x and 9.x so we could safely migrate our servers without having to
> coordinate a code push. It wasn't that bad, but part of the problem is that
> the DBD::Pg driver does not understand the new format... but it does
> unescape the "\x" marker for me to a simple "x", since that follows the
> traditional un-escaping rules for values returned from Pg. I don't like
> overriding defaults in the DB settings unless I *really* have to.
Although DBD::Pg uses libpq, linking it with the PostgreSQL-9.0 libpq
doesn't fix the escape/unescape problem. (I'm sure you already know this.)
That's because DBD::Pg implements its own string and bytea escape and
unescape functions, for some reason, and does not use PQescapeStringConn
etc. (I wonder if that makes it vulnerable to the security problems fixed
8.1.4?)
I probably would have just gone ahead and deployed 9.0 servers with
"bytea_output='escape'" in their postgresql.conf files. Permanent work-around.
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: [GENERAL] Gripe: bytea_output default => data corruption
@ 2010-10-25 23:18 Tom Lane <tgl@sss.pgh.pa.us>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 21+ messages in thread
From: Tom Lane @ 2010-10-25 23:18 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: ljb <ljb9832@pobox.com>; pgsql-docs
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
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: [GENERAL] Gripe: bytea_output default => data corruption
@ 2010-10-27 01:11 ljb <ljb9832@pobox.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 21+ messages in thread
From: ljb @ 2010-10-27 01:11 UTC (permalink / raw)
To: pgsql-docs
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.
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: [GENERAL] Gripe: bytea_output default => data corruption
@ 2011-02-02 21:25 Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 21+ messages in thread
From: Bruce Momjian @ 2011-02-02 21:25 UTC (permalink / raw)
To: ljb <ljb9832@pobox.com>; +Cc: pgsql-docs
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. +
Attachments: download all (2 files, .tar.gz)
/rtmp/libpq.diff (text/x-diff, 3.4K) download
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>
/rtmp/libpq.diff (text/x-diff, 2.5K) download
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
@ 2011-02-02 21:27 Bruce Momjian <bruce@momjian.us>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 21+ messages in thread
From: Bruce Momjian @ 2011-02-02 21:27 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: ljb <ljb9832@pobox.com>; pgsql-docs
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. +
Attachments:
/rtmp/libpq.diff (text/x-diff, 3.4K) download
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
@ 2011-02-03 19:38 ljb <ljb9832@pobox.com>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 21+ messages in thread
From: ljb @ 2011-02-03 19:38 UTC (permalink / raw)
To: pgsql-docs
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.
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: [GENERAL] Gripe: bytea_output default => data corruption
@ 2011-02-04 21:14 Bruce Momjian <bruce@momjian.us>
parent: ljb <ljb9832@pobox.com>
0 siblings, 1 reply; 21+ messages in thread
From: Bruce Momjian @ 2011-02-04 21:14 UTC (permalink / raw)
To: ljb <ljb9832@pobox.com>; +Cc: pgsql-docs
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. +
Attachments:
/rtmp/libpq.diff (text/x-diff, 6.2K) download
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
@ 2011-02-04 23:27 ljb <ljb9832@pobox.com>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 21+ messages in thread
From: ljb @ 2011-02-04 23:27 UTC (permalink / raw)
To: pgsql-docs
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.)
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: [GENERAL] Gripe: bytea_output default => data corruption
@ 2011-02-05 01:34 Bruce Momjian <bruce@momjian.us>
parent: ljb <ljb9832@pobox.com>
0 siblings, 1 reply; 21+ messages in thread
From: Bruce Momjian @ 2011-02-05 01:34 UTC (permalink / raw)
To: ljb <ljb9832@pobox.com>; +Cc: pgsql-docs
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. +
Attachments:
/rtmp/libpq.diff (text/x-diff, 6.1K) download
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
@ 2011-02-06 02:35 ljb <ljb9832@pobox.com>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 21+ messages in thread
From: ljb @ 2011-02-06 02:35 UTC (permalink / raw)
To: pgsql-docs
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.
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: [GENERAL] Gripe: bytea_output default => data corruption
@ 2011-02-13 14:52 Bruce Momjian <bruce@momjian.us>
parent: ljb <ljb9832@pobox.com>
0 siblings, 0 replies; 21+ messages in thread
From: Bruce Momjian @ 2011-02-13 14:52 UTC (permalink / raw)
To: ljb <ljb9832@pobox.com>; +Cc: pgsql-docs
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. +
^ permalink raw reply [nested|flat] 21+ messages in thread
end of thread, other threads:[~2011-02-13 14:52 UTC | newest]
Thread overview: 21+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2010-10-13 00:37 Gripe: bytea_output default => data corruption ljb <ljb9832@pobox.com>
2010-10-13 07:45 ` Raymond O'Donnell <rod@iol.ie>
2010-10-13 12:48 ` Dmitriy Igrishin <dmitigr@gmail.com>
2010-10-13 21:03 ` ljb <ljb9832@pobox.com>
2010-10-14 09:15 ` Raymond O'Donnell <rod@iol.ie>
2010-10-14 09:19 ` Rajesh Kumar Mallah <mallah.rajesh@gmail.com>
2010-10-21 21:29 ` Bruce Momjian <bruce@momjian.us>
2010-10-21 23:12 ` ljb <ljb9832@pobox.com>
2010-10-21 23:42 ` Bruce Momjian <bruce@momjian.us>
2010-10-25 23:18 ` Tom Lane <tgl@sss.pgh.pa.us>
2010-10-27 01:11 ` ljb <ljb9832@pobox.com>
2010-10-22 16:19 ` Vick Khera <vivek@khera.org>
2010-10-22 22:06 ` ljb <ljb9832@pobox.com>
2011-02-02 21:25 Re: [GENERAL] Gripe: bytea_output default => data corruption Bruce Momjian <bruce@momjian.us>
2011-02-02 21:27 ` Bruce Momjian <bruce@momjian.us>
2011-02-03 19:38 ` ljb <ljb9832@pobox.com>
2011-02-04 21:14 ` Bruce Momjian <bruce@momjian.us>
2011-02-04 23:27 ` ljb <ljb9832@pobox.com>
2011-02-05 01:34 ` Bruce Momjian <bruce@momjian.us>
2011-02-06 02:35 ` ljb <ljb9832@pobox.com>
2011-02-13 14:52 ` Bruce Momjian <bruce@momjian.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox