Re: a contrib function to query current locale values - Mailing list pgsql-hackers

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