Re: Locale support is now on by default
От | Peter Eisentraut |
---|---|
Тема | Re: Locale support is now on by default |
Дата | |
Msg-id | Pine.LNX.4.30.0204031223360.684-100000@peter.localdomain обсуждение исходный текст |
Ответ на | Re: Locale support is now on by default (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Locale support is now on by default
Re: Locale support is now on by default |
Список | 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 по дате отправления: