From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | "Magnus Hagander" <mha(at)sollentuna(dot)net>, "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>, "Patches" <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: Show encoding in initdb messages |
Date: | 2004-06-21 16:03:38 |
Message-ID: | 3220.1087833818@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> But the answer space is infinite:
> $ LANG=C locale charmap
> ANSI_X3.4-1968
Right, the hard part is mapping whatever weird string "locale charmap"
chooses to return into one of the encodings our code knows about.
HPUX seems to be just arbitrarily bizarre:
$ LC_ALL=en_US.iso88591 locale charmap
"iso88591.cm"
$ LC_ALL=C.utf8 locale charmap
"utf8.cm"
$
As near as I can tell, the .cm is present in all the possible results;
and why the quotes?
> I suspect Japanese users will also have a problem with this mechanism,
> but at least we could keep -E to override the automatic selection.
Perhaps we could try to derive a setting from locale charmap, but barf
and require explicit -E if we can't recognize it?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2004-06-21 16:22:19 | Re: Show encoding in initdb messages |
Previous Message | Peter Eisentraut | 2004-06-21 15:46:56 | Re: Show encoding in initdb messages |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2004-06-21 16:22:19 | Re: Show encoding in initdb messages |
Previous Message | Peter Eisentraut | 2004-06-21 15:46:56 | Re: Show encoding in initdb messages |