Lamar Owen <[EMAIL PROTECTED]> writes:
> ... The initdb locale
> settings are stored in initdb.i18n, and they are re-sourced everytime
> postgresql is started to prevent data corruption if postmaster is started
> with a different locale from the initdb. Tom, is the data corruption issue
> still an issue with 7.4.x, or is this just historical?
That's historical. For several versions now, the LC_COLLATE and
LC_CTYPE settings seen by initdb have been saved in pg_control and
re-adopted by the postmaster at start, so that index order corruption
problems are impossible. We do still adopt other settings such as
LC_MESSAGES from the postmaster environment, although I believe that
these will generally be read from postgresql.conf if you haven't toyed
with what initdb puts into that file.
In short then I doubt there's a need for initdb.i18n anymore. It would
make more sense to have postgres' bash_profile source /etc/sysconfig/i18n
directly.
The question of what postgresql.init should do if there's no available
LANG or LC_ALL setting seems orthogonal to me. I do not find Trond's
arguments convincing at all: a person who feels that C locale is broken
ought to set up /etc/sysconfig/i18n to specify another locale. The
POSIX standards say that the default locale in the absence of any
environmental variable is C, not en_US, and the fact that Trond doesn't
like that default doesn't give him license to change it, nor IMHO to try
to make an end run around the standard by pressuring initscript authors
to override the POSIX spec. I have no objection to making en_US the
default at the sysconfig level, but inserting it in lower levels of the
system seems at best misguided.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
