Re: BUG #5720: Bug for PQescapeByteaConn (libpq) - Mailing list pgsql-bugs

From Craig Ringer
Subject Re: BUG #5720: Bug for PQescapeByteaConn (libpq)
Date
Msg-id 4CC268A7.3000302@postnewspapers.com.au
Whole thread Raw
In response to Re: BUG #5720: Bug for PQescapeByteaConn (libpq)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #5720: Bug for PQescapeByteaConn (libpq)
Re: BUG #5720: Bug for PQescapeByteaConn (libpq)
List pgsql-bugs
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/

pgsql-bugs by date:

Previous
From: Alexia Lau
Date:
Subject: Re: BUG
Next
From: Tom Lane
Date:
Subject: Re: BUG #5720: Bug for PQescapeByteaConn (libpq)