| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
| Cc: | Gevik Babakhani <pgdev(at)xs4all(dot)nl>, "'Magnus Hagander'" <magnus(at)hagander(dot)net>, pgsql-patches(at)postgresql(dot)org |
| Subject: | Re: Fix for 8.3 MSVC locale (Was [HACKERS] NLS on MSVC strikes back!) |
| Date: | 2008-02-14 22:39:54 |
| Message-ID: | 20152.1203028794@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-patches |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Ideally, it should be an error to set lc_messages to a value that's not
> compatible with the current encoding. Do we do that currently elsewhere?
We don't currently enforce that, and I'm not sure it's possible to do so
on non-Windows machines. AFAIR the POSIX API doesn't even associate a
character set with anything but LC_CTYPE.
Does it make any sense to wire in the assumption that locale names have
the form "something.encoding-id"? If we did that, we could enforce that
the encoding-id part matches LC_CTYPE, or maybe even just alter the
presented values for other LC_foo variables to match.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gevik Babakhani | 2008-02-14 22:58:01 | Re: Fix for 8.3 MSVC locale (Was [HACKERS] NLS on MSVCstrikes back!) |
| Previous Message | Alvaro Herrera | 2008-02-14 22:35:42 | Re: Fix for 8.3 MSVC locale (Was [HACKERS] NLS on MSVC strikes back!) |