From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
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 |
Subject: | Re: Determining client_encoding from client locale |
Date: | 2009-06-18 05:36:38 |
Message-ID: | 4A39D266.4030707@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Itagaki Takahiro wrote:
> 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.
>
> I think automatic determination is good for psql because it is
> an end-user application, but is not always acceptable for middlewares.
>
> Please imagine:
>
> Web Server <- Application Server <- Database Server
> ---------- ------------------ ---------------
> UTF-8 Non-UTF8 env. UTF-8
>
> The Application Server might run on non-UTF8 environment
> but it should send outputs in UTF8 encoding. Automatic
> encoding determination might break existing services.
As soon as someone creates a database in non-UTF-8 encoding in the
cluster, it would stop working anyway. Setting client_encoding=utf8
manually would be a lot safer in a situation like that.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2009-06-18 06:38:27 | Re: [HACKERS] Cannot use all four trigger events at once |
Previous Message | Robert Haas | 2009-06-18 03:43:30 | machine-readable explain output v2 |