Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-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

pgsql-hackers by date

Next:From: Tom LaneDate: 2008-12-08 00:17:25
Subject: Re: Assertion failure in new outer/semi/anti join code
Previous:From: Dmitry KoterovDate: 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 LaneDate: 2008-12-08 01:16:17
Subject: Re: BUG #4567: Clustering on GIST INDEX clobbers records in table intermittently
Previous:From: Regina ObeDate: 2008-12-07 20:34:43
Subject: BUG #4567: Clustering on GIST INDEX clobbers records in table intermittently

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group