Re: BUG #4186: set lc_messages does not work

From: "Gevik Babakhani" <pgdev(at)xs4all(dot)nl>
To: "'Bruce Momjian'" <bruce(at)momjian(dot)us>
Cc: "'Magnus Hagander'" <magnus(at)hagander(dot)net>, "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "'Thomas H(dot)'" <me(at)alternize(dot)com>, <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #4186: set lc_messages does not work
Date: 2008-12-07 23:50:08
Message-ID: C414644A633A437AB6A5E1F3D36F305F@gevmus
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

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
itself.

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.

Any thoughts?

Regards,
Gevik Babakhani
------------------------------------------------
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.';
> pgsql-bugs(at)postgresql(dot)org
> 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
> Babakhani
> > > 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
> > > >>
> http://archives.postgresql.org/pgsql-patches/2008-02/msg00038.php
> > > >> 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

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2008-12-08 01:16:17 Re: BUG #4567: Clustering on GIST INDEX clobbers records in table intermittently
Previous Message Regina Obe 2008-12-07 20:34:43 BUG #4567: Clustering on GIST INDEX clobbers records in table intermittently

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-12-08 00:17:25 Re: Assertion failure in new outer/semi/anti join code
Previous Message Dmitry Koterov 2008-12-07 20:49:24 Re: ALTER composite type does not work, but ALTER TABLE which ROWTYPE is used as a type - works fine