a contrib function to query current locale values

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 responsibility alone. Under this section, the
Commercial Contributor would have to defend claims against the other
Contributors related 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