Обсуждение: BUG #1583: Locale problem

The following bug has been logged online:

Bug reference:      1583
Logged by:          Andrew Grillet
Email address:      andrew@grillet.co.uk
PostgreSQL version: 7.4.7
Operating system:   FreeBSD 5.3
Description:        Locale problem
Details:

error message XX000: cannot assign "" to LC_messages - or something like
this.

The cause appears to be that line 1414 of guc.c has a null string in place
of "C", at any rate, when I changed "" to "C" the problem went away.

The error message was not very helpful, and there might be some way to work
around this, but I couldn't find it. The work-arounds suggested by Linux
people did not seem to work on FreeBSD.

The locale documentation in the manual suggests that all locales listed by
"locale -a" will work. I could not get en_GB or en or en_GB.ISO5589.1 to
work, but all are listed by locale -a. (I dont really want locale support
anyway, I just want European dates.)

"Andrew Grillet" <andrew@grillet.co.uk> writes:
> error message XX000: cannot assign "" to LC_messages - or something like
> this.

We've seen this before but AFAIR no one has ever really satisfactorily
explained what's happening.  Assigning an empty string *should* work;
the definition of setlocale is that it's supposed to select the default
locale.  It's difficult to believe that selecting the default locale
does not work.

If you check the archives you will definitely find this mentioned in
connection with Mac OS X.  Not sure if we've heard it before for FreeBSD
or not.  What FreeBSD release have you got exactly, and what locale
environment were you starting the postmaster in?  Did you have
nondefault values for any of the other LC_xxx settings?

> (I dont really want locale support
> anyway, I just want European dates.)

In that case you should stick with C locale and just set DateStyle.
But if you'd like to help track down this locale failure first ...

            regards, tom lane

Andrew Grillet <andrew@grillet.co.uk> writes:
> Fix is found ...
> the default .csrc file set the locale to
> en_GB.ISO_5589-1

> but the correct setting is
> en_GB.ISO5589-1

> So the locale was set to an invalid setting. This has undesirable side
> effects.

Indeed ;-)

> It might be worth adding to the manual that
> --------------------8<---------------------
> In FreeBSD the selected locale  can be viewed by
> > locale

> and  available locales can be viewed by
> > locale -a

> if one or both of the above give improbable results, check
> your .csrc, .shrc and .profile.
> --------------------8<---------------------

Hmm, is this advice FreeBSD-specific?

I tried it on Linux and HP-UX, and in both cases "locale" made it
perfectly clear that there was something wrong:

$ LANG=bogus locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=bogus
LC_CTYPE="bogus"
LC_NUMERIC="bogus"
LC_TIME="bogus"
LC_COLLATE="bogus"
LC_MONETARY="bogus"
LC_MESSAGES="bogus"
LC_PAPER="bogus"
LC_NAME="bogus"
LC_ADDRESS="bogus"
LC_TELEPHONE="bogus"
LC_MEASUREMENT="bogus"
LC_IDENTIFICATION="bogus"
LC_ALL=
$

$ LANG=bogus locale

Warning! One or more of your selected locales are not available.
Please invoke the commands "locale" and "locale -a" to verify your
selections and the available locales.

Continuing processing using the "C" locale.

LANG=bogus
LC_CTYPE="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_MESSAGES="C"
LC_ALL=
$

I'm thinking we should (perhaps already do) mention the use of "locale"
to check for valid locale settings, but maybe it's not mentioned in the
most useful places.  Where were you thinking of inserting the above
snippet, anyway?

Anyone else have comments to make on this?

            regards, tom lane