Обсуждение: BUG #5720: Bug for PQescapeByteaConn (libpq)

The following bug has been logged online:

Bug reference:      5720
Logged by:          Eiichi Nakamura
Email address:      nakamura@nepsys.ddo.jp
PostgreSQL version: 9.0.1
Operating system:   Linux kernel 2.6.27
Description:        Bug for PQescapeByteaConn (libpq)
Details:

For PostgreSQL 9.0.1, after changing server "bytea_output" parameter as
"escape" in postgresql.conf file, it is expected that PQescapeByteaConn
(libpq) returns "escape" format.
However, PQescapeByteaConn still returns "hex" (server default) format.
Would you please modify PQescapeByteaConn behaviours for next release?
By the way, PQescapeBytea returns correct format.

"Eiichi Nakamura" <nakamura@nepsys.ddo.jp> writes:
> For PostgreSQL 9.0.1, after changing server "bytea_output" parameter as
> "escape" in postgresql.conf file, it is expected that PQescapeByteaConn
> (libpq) returns "escape" format.

Why do you expect that?  The parameter only controls the *server*'s
output, it is not suggested anywhere that it should have an effect
on clients.

            regards, tom lane

On 23/10/2010 1:11 AM, Tom Lane wrote:
> "Eiichi Nakamura"<nakamura@nepsys.ddo.jp>  writes:
>> For PostgreSQL 9.0.1, after changing server "bytea_output" parameter as
>> "escape" in postgresql.conf file, it is expected that PQescapeByteaConn
>> (libpq) returns "escape" format.
>
> Why do you expect that?  The parameter only controls the *server*'s
> output, it is not suggested anywhere that it should have an effect
> on clients.

IMO it seems like a reasonable expectation on the face of it. The client
can tell what bytea format the server wants, as it has a connection to
the server and the ability to read the appropriate GUC. The whole point
of the 'Conn' functions is that they're capable of being sensitive to
the configuration of the current connection.

That said, you don't want to do the GUC lookup every time you escape a
bytea, but you can't prove it hasn't been changed since you read it at
connect time or when the first PQescapeByteaConn call was made. To
achieve correct behaviour without a round-trip to the server for every
escape you'd need a way for the connection to be asynchronously notified
that the bytea_output GUC had changed.

I'm not at all sure what the right answer is here. I just wanted to
raise reasons why the OP isn't necessarily unreasonable in expecting the
behaviour they describe.

--
Craig Ringer

Tech-related writing at http://soapyfrogs.blogspot.com/

Craig Ringer <craig@postnewspapers.com.au> writes:
> On 23/10/2010 1:11 AM, Tom Lane wrote:
>> Why do you expect that?  The parameter only controls the *server*'s
>> output, it is not suggested anywhere that it should have an effect
>> on clients.

> I'm not at all sure what the right answer is here. I just wanted to
> raise reasons why the OP isn't necessarily unreasonable in expecting the
> behaviour they describe.

The definition of the PQescape functions is that they produce strings
that will be acceptable to the server they're connected to.  The OP
apparently wishes some other definition, but he's failed to put forward
any argument at all why it should be changed.

            regards, tom lane

On Saturday 23 October 2010 06:46:31 Craig Ringer wrote:
> On 23/10/2010 1:11 AM, Tom Lane wrote:
> > "Eiichi Nakamura"<nakamura@nepsys.ddo.jp>  writes:
> >> For PostgreSQL 9.0.1, after changing server "bytea_output" parameter as
> >> "escape" in postgresql.conf file, it is expected that PQescapeByteaConn
> >> (libpq) returns "escape" format.
> >
> > Why do you expect that?  The parameter only controls the *server*'s
> > output, it is not suggested anywhere that it should have an effect
> > on clients.
>
> IMO it seems like a reasonable expectation on the face of it. The client
> can tell what bytea format the server wants, as it has a connection to
> the server and the ability to read the appropriate GUC. The whole point
> of the 'Conn' functions is that they're capable of being sensitive to
> the configuration of the current connection.
The GUC controlls the output - it doesnt control the allowed input. The switch
on the client needs to get based on the version - which hopefully doesnt
change in a single connection ;-)


Andres

On 10/23/2010 10:19 PM, Andres Freund wrote:

> The GUC controlls the output - it doesnt control the allowed input. The switch
> on the client needs to get based on the version - which hopefully doesnt
> change in a single connection ;-)

Ah. Please disregard my comment, then.

--
Craig Ringer