REVIEW: Determining client_encoding from client locale

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, Magnus Hagander <magnus(at)hagander(dot)net>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
Subject: REVIEW: Determining client_encoding from client locale
Date: 2011-01-29 16:50:19
Message-ID: 20110129165019.GO30352@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greetings,

* Peter Eisentraut (peter_e(at)gmx(dot)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.

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..

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.

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-01-29 17:11:40 Re: pg_upgrade fails for non-postgres user
Previous Message Magnus Hagander 2011-01-29 16:15:35 Re: SSPI client authentication in non-Windows builds