On Tue, Jan 29, 2013 at 09:54:04AM -0500, Tom Lane wrote:
> Alexander Law <exclusion(at)gmail(dot)com> writes:
> > Please look at the following l10n bug:
> > http://www.postgresql.org/message-id/502A26F1.firstname.lastname@example.org
> > and the proposed patch.
> That patch looks entirely unsafe to me. Neither of those functions
> should be expected to be able to run when none of our standard
> infrastructure (palloc, elog) is up yet.
> Possibly it would be safe to do this somewhere around where we do
> GUC initialization.
Even then, I wouldn't be surprised to find problematic consequences beyond
error display. What if all the databases are EUC_JP, the platform encoding is
KOI8, and some postgresql.conf settings contain EUC_JP characters? Does the
postmaster not rely on its use of SQL_ASCII to allow those values?
I would look at fixing this by making the error output machinery smarter in
this area before changing the postmaster's notion of server_encoding.
In response to
pgsql-hackers by date
|Next:||From: Noah Misch||Date: 2013-01-30 02:04:56|
|Subject: Re: lazy_vacuum_heap()'s removal of HEAPTUPLE_DEAD tuples|
|Previous:||From: Noah Misch||Date: 2013-01-30 01:34:24|
|Subject: Re: COPY FREEZE has no warning|
pgsql-bugs by date
|Next:||From: Alexander Law||Date: 2013-01-30 06:00:01|
|Subject: Re: BUG #7493: Postmaster messages unreadable in a Windows console|
|Previous:||From: jan.mate||Date: 2013-01-29 23:50:14|
|Subject: BUG #7838: pg_dump major bug|
pgsql-general by date
|Next:||From: Tim Uckun||Date: 2013-01-30 02:58:54|
|Subject: Dropping default privileges.|
|Previous:||From: Kevin Grittner||Date: 2013-01-29 23:09:26|
|Subject: Re: Optimizing select count query which often takes over 10 seconds|