From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
---|---|
To: | peter_e(at)gmx(dot)net |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Automatic detection of client encoding |
Date: | 2003-05-28 23:16:07 |
Message-ID: | 20030529.081607.104030375.t-ishii@sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I strongly object this idea. We already have had enough trouble with
initdb because of its locale awareness (I still think we should turn
on the --no-locale switch by default).
--
Tatsuo Ishii
> It is a common problem that a server uses a nontrivial character set
> encoding (e.g., Unicode) but users forget to set an appropriate
> client-side encoding. Then they get bogus displays for non-ASCII
> characters because their client isn't actually prepared for Unicode.
>
> There is a standard interface (SUSv2) for detecting the character set
> based on the locale settings. I suggest we use this (if available) in
> applications like psql and pg_dump by default unless it is overridden by
> the usual mechanisms. If the character set name obtained this way is not
> recognized by PostgreSQL, we fall back to SQL_ASCII.
>
> Here's a piece of code that shows how this would work:
>
> #include <stdio.h>
> #include <locale.h>
> #include <langinfo.h>
>
> int
> main(int argc, char *argv[])
> {
> setlocale(LC_ALL, "");
> printf("%s\n", nl_langinfo(CODESET));
> return 0;
> }
>
> (LC_CTYPE is the governing category for this.)
>
> Comments?
>
> --
> Peter Eisentraut peter_e(at)gmx(dot)net
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-05-28 23:20:14 | Re: Automatic detection of client encoding |
Previous Message | Peter Eisentraut | 2003-05-28 21:56:07 | Automatic detection of client encoding |