AFAIK we did not discuss this further. LC_MESSAGES and changing locale
functionality for functions like to_date on windows remains broken.
To summarize the problem:
1) On *nix systems, we use lc_messages and lc_locale both for functions
(like to to_date and to_char) and other system messages where locale plays
any role. Lc_messages and lc_locale are read from the environment variables.
Unfortunately on Windows the meaning of these variables is not the same as
on *nix systems, resulting locale assignment behave unexpectedly (broken).
2) On both systems we are using gettext library which is responsible to read
and translate to the correct locale. Gettext on *nix and Windows (and MAC)
also has different implementations for the same functionality. Not to
mention we are using a very old version of gettext on Windows.
3) As I was working on the patch to fix this I encountered places where the
usage of LC_MESSAGES and LC_LOCALE was not clear, especially for functions
where the functionality of Oracle was mimicked.
4) The entire problem came to light when we started to compile PG with MSVC
(8.3+). On 8.2 which was compiled using MinGW (I guess we do not support it
anymore) the behavior of lc_messages and lc_locale was also broken but not
as visible as with MSVC.
5) To give you an example: On *nix, the locale system acts when the value of
lc_messages or lc_locale (environment variables) changes. The expected
values are like: "en_US". On Windows on the other hand, en_US has no
meaning. It becomes something like "English (United States)", which is
ignored by gettext. Leaving us with no alternative than translating the
"English (United States)" to "en_US" and force it to gettext which does not
work all the time because gettext discards the forced value when it reloads
6) As I mentioned before, I stopped developing a patch for this because this
problem is somewhat deeper than it appears. Any attempt to fix this problem
will also result changing code for both locale aware functions like to_date
and to_char as for when to use lc_locale and lc_messages in the codebase.
PostgreSQL NL http://www.postgresql.nl
TrueSoftware BV http://www.truesoftware.nl
> -----Original Message-----
> From: Bruce Momjian [mailto:bruce(at)momjian(dot)us]
> Sent: Sunday, December 07, 2008 4:26 AM
> To: Gevik Babakhani
> Cc: 'Magnus Hagander'; 'Tom Lane'; 'Thomas H.';
> Subject: Re: [BUGS] BUG #4186: set lc_messages does not work
> Gevik Babakhani wrote:
> > My apologies on this late reply.
> > The way LC_MESSAGES is handled on windows is much less
> efficient and faulty.
> > While ago I started with a patch to fix some of the issues I
> > encountered on windows and LC_MESSAGES. But I stopped
> working on that
> > patch because this problem needed to be fixed on many other
> places. In
> > Windows, handling LC_MESSAGES will not work the same way as *nix
> > systems, forcing us to make ugly workarounds. (as I
> actually was doing
> > with my patch)
> > To my opinion, unless we think of a coherent solution for handling
> > LC_MESSAGES/locale for both *nix and win32 platforms, fixing
> > lc_messages and locale issues would break more than fixing it.
> > BTW: The gettext library we are using on win32 is a very old one.
> This is the most recent posting on the topic, I think. Status?
> > Regards,
> > Gevik.
> > > -----Original Message-----
> > > From: Magnus Hagander [mailto:magnus(at)hagander(dot)net]
> > > Sent: Tuesday, August 05, 2008 4:54 PM
> > > To: Bruce Momjian
> > > Cc: Tom Lane; Thomas H.; pgsql-bugs(at)postgresql(dot)org; Gevik
> > > Subject: Re: [BUGS] BUG #4186: set lc_messages does not work
> > >
> > > Bruce Momjian wrote:
> > > > Tom Lane wrote:
> > > >> Magnus Hagander <magnus(at)hagander(dot)net> writes:
> > > >>> Thomas H. wrote:
> > > >>>> so at least that explains the "changed" behaviour.
> > > >>>> nevertheless, LC_MESSAGES seems to be defunct - with
> the "locale"
> > > folder present,
> > > >>>> pg always picks the os' language and ignores the
> > > lc_message value.
> > > >>> This looks like I can reproduce though, at least on cvs head.
> > > >>> Did this work for you in previous versions?
> > > >> Maybe we were using a different build of gettext in
> the previous
> > > >> releases, one that didn't look at the same info as the
> > > current code?
> > > >>
> > > >> Anyway the patch mentioned at the start of the thread
> > > >>
> > > >> purports to fix this. It doesn't seem to have gotten reviewed
> > > >> though.
> > > >
> > > > Agreed. Magnus, someone, can we get feedback on the patch
> > > at this URL?
> > > >
> > > >
> > > http://archives.postgresql.org/pgsql-patches/2008-02/msg00038.php
> > >
> > > IIRC, there was further work to be done on the patch
> before it was
> > > to be applied, and we held off the review until then.
> > >
> > > Gevik - can you comment on this? Where are we, what needs
> ot be done
> > > still?
> > >
> > > //Magnus
> > >
> Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
> + If your life is a hard drive, Christ can be your backup. +
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2008-12-08 00:17:25|
|Subject: Re: Assertion failure in new outer/semi/anti join code |
|Previous:||From: Dmitry Koterov||Date: 2008-12-07 20:49:24|
|Subject: Re: ALTER composite type does not work, but ALTER TABLE which ROWTYPE is used as a type - works fine|
pgsql-bugs by date
|Next:||From: Tom Lane||Date: 2008-12-08 01:16:17|
|Subject: Re: BUG #4567: Clustering on GIST INDEX clobbers records in table intermittently |
|Previous:||From: Regina Obe||Date: 2008-12-07 20:34:43|
|Subject: BUG #4567: Clustering on GIST INDEX clobbers records in table intermittently|