| From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Dennis Björklund <db(at)zigo(dot)dhs(dot)org>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Translations in the distributions |
| Date: | 2004-01-09 21:35:28 |
| Message-ID: | 200401092235.28964.peter_e@gmx.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
> So the problem really occurs when database_encoding is set to an
> encoding that is incompatible with the one implied by the initdb-time
> LC_CTYPE ... which we have no good way to check. Ugh.
>
> I have some vague recollection that glibc offers an API extension
> that allows this to be checked. Is it worth having a solution that
> catches the problem on glibc only?
The problem is more likely to be that it will be hard to match up the
different encoding names. For example, if you set LC_CTYPE=C, then the
system encoding is report as
$ locale charmap
ANSI_X3.4-1968
whereas the closest thing in PostgreSQL would be SQL_ASCII.
It might already help if we allowed LC_CTYPE to be attached to a
database rather than the entire cluster, and make the user match them
up manually. The only drawback would be that indexes on global tables
involving upper() or lower() would no longer work reliably.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2004-01-09 22:04:16 | Re: Encoding problems in PostgreSQL with XML data |
| Previous Message | Merlin Moncure | 2004-01-09 21:35:08 | Re: Encoding problems in PostgreSQL with XML data |