Re: Determining client_encoding from client locale
От | Tom Lane |
---|---|
Тема | Re: Determining client_encoding from client locale |
Дата | |
Msg-id | 17895.1245361871@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Determining client_encoding from client locale (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: Determining client_encoding from client locale
|
Список | pgsql-hackers |
Bruce Momjian <bruce@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
В списке pgsql-hackers по дате отправления: