Re: REVIEW: Determining client_encoding from client locale
От | Peter Eisentraut |
---|---|
Тема | Re: REVIEW: Determining client_encoding from client locale |
Дата | |
Msg-id | 1296321836.11516.15.camel@vanquo.pezone.net обсуждение исходный текст |
Ответ на | REVIEW: Determining client_encoding from client locale (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: REVIEW: Determining client_encoding from client locale
|
Список | pgsql-hackers |
On lör, 2011-01-29 at 11:50 -0500, Stephen Frost wrote: > Greetings, > > * Peter Eisentraut (peter_e@gmx.net) wrote: > > I have adjusted your old patch for the current tree, and it seems to > > work. I think it was just forgotten last time because the move to > > PQconnectdbParams had to happen first. But I'll throw it back into the > > ring now. > > Right off the bat, I don't like that you removed the references to SET > client_encoding from the documentation, that strikes me as a good thing > to keep, though it could go under the client_encoding varname > documentation that you added. I don't follow completely. What was changed was that instead of documenting that PGCLIENTENCODING is equivalent to SET client_encoding, it was changed to say that PGCLIENTENCODING corresponds to the client_encoding connection option, and the client_encoding connection option documents that it is similar to the client_encoding server parameter. Maybe some wordsmithing could be applied, but I don't think any information was actually removed. > Also, do we really need a new set of states for this..? I would have > thought, just reading through the patch, that we could use the existing > OPTION_SEND/OPTION_WAIT states.. Don't know. Maybe Heikki could comment; he wrote that initially. > I'll be going through the patch in more detail, testing, etc, and will > probably go ahead and do the documentation/comment updates myself, > unless someone cares. Sounds good to me.
В списке pgsql-hackers по дате отправления: