Thread: a contrib function to query current locale values

Hi,

I've written a small function that should go into contrib for 7.1

As locale issues are quite tricky, being able to find out what locale
backend thinks it is in is a good thing ;)

from my README.getlocale:

getlocale('category')
---------------------

return the locale setting of the backend
(see '> man setlocale for definitions)

If category is one of LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY,
LC_NUMERIC, LC_TIME the corresponding setting is returned.

[hannu@taru contrib]$ psql -c "select getlocale('LC_COLLATE')"
 getlocale
-----------
 en_US
(1 row)


for LC_ALL (and anything else) a string like the following is returned


[hannu@taru getlocale]$ psql -c "select getlocale('*')"
                                       getlocale
----------------------------------------------------------------------------------------

LC_CTYPE=en_US;LC_NUMERIC=C;LC_TIME=C;LC_COLLATE=en_US;LC_MONETARY=en_US;LC_MESSAGES=C
(1 row)


IMHO some form of it should end up in the main distribution, probably by
7.2.

---------------------------------
Hannu Krosing <hannu@krosing.net>

On Wed, 7 Feb 2001, Hannu Krosing wrote:

> 
> Hi,
> 
> I've written a small function that should go into contrib for 7.1
> 
> As locale issues are quite tricky, being able to find out what locale 
> backend thinks it is in is a good thing ;)
hmm, see you PG sources -- pg_locale.c file?
I mean that is not good lavish the sources with same code. If this is
really needful will better add your idea into this file and use
PGLC_current() instead add to sources again new setlocale() call.
The current backend (unfortunately) disable change locales on the fly 
-- this means your function will returns always same result :-)
IMHO more nice will some function 'environment()' returns *all* backend
environment values (locales, debug mode ... etc) or command "SHOW LOCALE"
or something like this.
        Karel

Karel Zak wrote:

> On Wed, 7 Feb 2001, Hannu Krosing wrote:
> 
> 
>> Hi,
>> 
>> I've written a small function that should go into contrib for 7.1
>> 
>> As locale issues are quite tricky, being able to find out what locale 
>> backend thinks it is in is a good thing ;)
> 
> 
>  hmm, see you PG sources -- pg_locale.c file?
> 
>  I mean that is not good lavish the sources with same code. If this is
> really needful will better add your idea into this file and use
> PGLC_current() instead add to sources again new setlocale() call.

Yes, pg_locale.c is where I want them to end up, but it is probably 
considered "a feature" and not "a bugfix" so it has to wait at least
until 7.2.

OTOH, piggipacking it upon PGLC_current() seems like an overkill as most 
of the code is not aboult setlocale(CONST,NULL) but for interfacing to 
postgres and 'LC_XXX' --> const LC_XXX conversions.

>  The current backend (unfortunately) disable change locales on the fly 

I think that is a well-founded restriction, we don't allow changing int4 
to char(4) on the fly either ;)

BTW, does anyone know if setlocale() is an expensive function ?

I.e. would it be a huge performance hog if called before each and every 
compare of each and every VARCHAR() or TEXT field that has COLLATE defined.

I'd guess it is, but if if it is not, we could use system-native locale 
support for STRING COLLATE.

> -- this means your function will returns always same result :-)

So does "select version();" which I still use quite often.

My concern is about knowing that "same" result - currently my ways for 
finding out about the locale included things like "select 
upper('õöäü');" and sorting a small specially created table - not most 
intuitive.

I needed to do it when I had to find out the simplest way to start 
postgres with different locale than the system default - the init 
scripts in the RPM's are several levels deep so I tried setting LC_ALL 
and/or friends at several levels (init.d/postgres, pg_ctl, 
~postgres/.bash_profile) and was quite unhappy by not being able to
know if it worked.

>  IMHO more nice will some function 'environment()' returns *all* backend
> environment values (locales, debug mode ... etc) or command "SHOW LOCALE"
> or something like this.

I'd prefer a separate function, as it seems most portable between 
different front-ends (no front-end changes needed ;).

It could have a special name, like pg_getlocale() to avoid
name-space pollution. (maybe version()->pg_version() would also
be a good move).

---------------
Hannu

Hannu Krosing <hannu@tm.ee> writes:
> BTW, does anyone know if setlocale() is an expensive function ?

The variant where you're just querying the current setting should not be
too expensive.  I'd expect the variant where you are changing the
setting to be very expensive, however; most likely, it goes out and
reads/parses the locale definition files.

> I.e. would it be a huge performance hog if called before each and every 
> compare of each and every VARCHAR() or TEXT field that has COLLATE defined.

I do not think we will be able to get away with that in standard
implementations of the locale functions.  We will need to roll our own
implementation that caches and reuses pre-loaded locale information for
multiple locales at once.

Doesn't seem like an appetizing prospect, but I think there's no other
way to support per-column locales...
        regards, tom lane

Tom Lane wrote:
> 
> Hannu Krosing <hannu@tm.ee> writes:
> > BTW, does anyone know if setlocale() is an expensive function ?
> 
> The variant where you're just querying the current setting should not be
> too expensive.  I'd expect the variant where you are changing the
> setting to be very expensive, however; most likely, it goes out and
> reads/parses the locale definition files.
> 
> > I.e. would it be a huge performance hog if called before each and every
> > compare of each and every VARCHAR() or TEXT field that has COLLATE defined.
> 
> I do not think we will be able to get away with that in standard
> implementations of the locale functions.  We will need to roll our own
> implementation that caches and reuses pre-loaded locale information for
> multiple locales at once.
> 
> Doesn't seem like an appetizing prospect, but I think there's no other
> way to support per-column locales...
> 
>                         regards, tom lane

There seems to be a library released by IBM that we could use, see at:

http://oss.software.ibm.com/developerworks/opensource/icu/project/

could someone review its license :

http://oss.software.ibm.com/developer/opensource/license10.html 

for compatibility with postgres.

At cursory reading it seems to have the same flaws that GPL :
---8<--------8<-------8<-------8<-------8<----
When the Program is made available in source code form: 
        a) it must be made available under this Agreement; and 
        b) a copy of this Agreement must be included with each copy of
the Program. 
---8<--------8<-------8<-------8<-------8<----
i.e. forcing its own license. 

OTOH it

1) allows distribution in object-code form under other licenses

2) is in fact a library not a "Program" ;)


3) it claims commercial distribution to be ok.
---8<--------8<-------8<-------8<-------8<----
4. COMMERCIAL DISTRIBUTION 
 Commercial distributors of software may accept certain
responsibilities with  respect to end users, business partners and the like. While this
license is  intended to facilitate the commercial use of the Program, the
Contributor  who includes the Program in a commercial product offering should do so
in a  manner which does not create potential liability for other
Contributors.  Therefore, if a Contributor includes the Program in a commercial
product  offering, such Contributor ("Commercial Contributor") hereby agrees to
defend and indemnify every other Contributor ("Indemnified Contributor")
against any losses, damages and costs (collectively "Losses") arising from claims,
lawsuits and other legal actions brought by a third party against the
Indemnified Contributor to the extent caused by the acts or omissions of such
Commercial Contributor in connection with its distribution of the Program in a
commercial product offering. The obligations in this section do not apply to any
claims or Losses relating to any actual or alleged intellectual property
infringement. In order to qualify, an Indemnified Contributor must: a) promptly
notify the Commercial Contributor in writing of such claim, and b) allow the
Commercial Contributor to control, and cooperate with the Commercial Contributor
in, the defense and any related settlement negotiations. The Indemnified
Contributor may participate in any such claim at its own expense. 
 For example, a Contributor might include the Program in a commercial
product offering, Product X. That Contributor is then a Commercial
Contributor. If that Commercial Contributor then makes performance claims, or offers
warranties related to Product X, those performance claims and warranties are such Commercial Contributor's
responsibilityalone. Under this section, the Commercial Contributor would have to defend claims against the other
Contributorsrelated to those performance claims and warranties, and
 
if a court requires any other Contributor to pay any damages as a result,
the Commercial Contributor must pay those damages. 
---8<--------8<-------8<-------8<-------8<----
--------
Hannu