Bruce Momjian <br...@momjian.us> writes:
> Tom Lane wrote:
>> What would make sense to me is for libpq to provide the *code* for this,
>> but then leave it up to the client application whether to actually call
>> it; if not the behavior stays the same as before. Aside from
>> Itagaki-san's objections, that eliminates backwards-compatibility issues
>> for other applications.
> Added to TODO:
BTW, something that occurred to me later is that the details of this
could easily be got wrong. If libpq is indeed told to get
client_encoding from the client environment, it should arrange to do so
*before* opening the connection, and send the encoding request as part
of the startup packet. The alternative of providing a function to
adjust the encoding for an already-opened connection is inferior for
a couple of reasons:
* extra network round trip required
* we lose any chance at ensuring that connection failure messages come
back in the client's desired encoding.
(The latter business was already discussed a bit IIRC, but I'm too lazy
to check the archives right now.)
So that means that the API for this should probably involve some
addition to the PQconnectdb parameter string, not a separate function.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
