Determining client_encoding from client locale - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Determining client_encoding from client locale
Date
Msg-id 4A38D396.1040003@enterprisedb.com
Whole thread Raw
Responses Re: Determining client_encoding from client locale  (Andrew Dunstan <andrew@dunslane.net>)
Re: Determining client_encoding from client locale  (Peter Eisentraut <peter_e@gmx.net>)
Re: Determining client_encoding from client locale  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
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.

client_encoding defaults to server_encoding, which is correct in the 
typical environment where the client and the server have identical 
locale settings, which I believe is why we don't see more confused users 
on mailing lists. However, a partner of ours was recently bitten by 
this. That was on Windows; I'm not 100% sure if LC_CTYPE is set 
correctly there by default, but this seems like a good idea nevertheless.

We could expand that to datestyle and the user-settable lc_* settings, 
but I don't want to go that far. In case the server lc_ctype/collate 
settings don't match the client's locale, you would end up with mixed 
lc_* settings which might be more confusing than helpful.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Gurjeet Singh
Date:
Subject: Re: [PATCH] backend: compare word-at-a-time in bcTruelen
Next
From: Stefan Kaltenbrunner
Date:
Subject: Re: [PATCH] backend: compare word-at-a-time in bcTruelen