Re: Locale support is now on by default - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Locale support is now on by default
Date
Msg-id Pine.LNX.4.30.0204031223360.684-100000@peter.localdomain
Whole thread Raw
In response to Re: Locale support is now on by default  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Locale support is now on by default  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Locale support is now on by default  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Tom Lane writes:

> It might be that Bruce's recent changes to elog levels allow a graceful
> compromise about backend messages during initdb.  I haven't looked, but
> maybe initdb could run the backend with message level one notch higher
> than LOG to suppress all the normal-case messages without masking not-
> so-normal cases.

There doesn't seem to be a way to turn off LOG without hiding almost
everything:
if (lev == LOG || lev == COMMERROR){    if (server_min_messages == LOG)        output_to_server = true;    else if
(server_min_messages< FATAL)        output_to_server = true;}
 

Everything except for PANIC is less than FATAL, so this doesn't make sense
to me.

Nonetheless, I don't like the way this message comes out.  It destroys
the, er, well-formed display that initdb gives.  Moreover, it's not really
a WARNING, meaning something is wrong.  I was thinking about handling this
within initdb, with a display like this:

"""
The files belonging to this database system will be owned by user "peter".
This user must also own the server process.

Locale settings: collate=en_US ctype=en_US [...]
(This locale will prevent optimization of LIKE and regexp searches.)

creating directory pg-install/var/data... ok
creating directory pg-install/var/data/base... ok
[...]
"""

Yes, we'd need to duplicate some code within initdb, but it's not like
that list of LIKE-safe locales is very dynamic.

-- 
Peter Eisentraut   peter_e@gmx.net



pgsql-hackers by date:

Previous
From: mlw
Date:
Subject: Re: Suggestions please: names for function cachability
Next
From: Tom Lane
Date:
Subject: Re: Suggestions please: names for function cachability