| From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
|---|---|
| To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Determining client_encoding from client locale |
| Date: | 2009-06-17 11:29:26 |
| Message-ID: | 4A38D396.1040003@enterprisedb.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stefan Kaltenbrunner | 2009-06-17 12:41:56 | Re: [PATCH] backend: compare word-at-a-time in bcTruelen |
| Previous Message | Stefan Kaltenbrunner | 2009-06-17 10:55:31 | Re: [PATCH] backend: compare word-at-a-time in bcTruelen |