From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Subject: | Re: Determining client_encoding from client locale |
Date: | 2009-06-18 01:11:20 |
Message-ID: | 18850.1245287480@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> writes:
> Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>> On Wednesday 17 June 2009 14:29:26 Heikki Linnakangas wrote:
>>> We currently require that you set client_encoding correctly, or you get
>>> garbage in psql and any other tool using libpq. How about setting
>>> client_encoding automatically to match the client's locale? We have
>>> pg_get_encoding_from_locale() function that we can use to extract the
>>> encoding from LC_CTYPE. We could call that in libpq.
> +1 for psql, but -1 for libpq.
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-06-18 01:18:33 | generic explain options v3 |
Previous Message | Itagaki Takahiro | 2009-06-18 00:57:19 | Re: Determining client_encoding from client locale |