From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
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 15:59:33 |
Message-ID: | 24170.1073663973@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Am Freitag, 9. Januar 2004 15:51 schrieb Tom Lane:
>> Hmm. So the problem would appear if LC_CTYPE is different from the
>> database encoding? Could we fix it by forcing LC_CTYPE to the database
>> encoding during startup?
> That would resolve quite a few problems, but I don't think there's a way to
> know what encoding a given LC_CTYPE value will result in.
Hmm. Actually it looks like we already do what I had in mind:
ReadControlFile():
if (setlocale(LC_CTYPE, ControlFile->lc_ctype) == NULL)
ereport(FATAL, ...
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?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2004-01-09 17:56:03 | Re: "with grant option" for user groups. |
Previous Message | Peter Eisentraut | 2004-01-09 15:46:10 | Re: Translations in the distributions |