Re: a contrib function to query current locale values

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