Re: BUG #5720: Bug for PQescapeByteaConn (libpq)

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: BUG #5720: Bug for PQescapeByteaConn (libpq)
Дата
Msg-id 4CC268A7.3000302@postnewspapers.com.au
обсуждение исходный текст
Ответ на Re: BUG #5720: Bug for PQescapeByteaConn (libpq)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: BUG #5720: Bug for PQescapeByteaConn (libpq)
Re: BUG #5720: Bug for PQescapeByteaConn (libpq)
Список 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 по дате отправления:

Предыдущее
От: Alexia Lau
Дата:
Сообщение: Re: BUG
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #5720: Bug for PQescapeByteaConn (libpq)