Re: Day and month name localization uses wrong locale category

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Euler Taveira de Oliveira <euler(at)timbira(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Day and month name localization uses wrong locale category
Date: 2006-11-24 16:26:46
Message-ID: 4438.1164385606@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Euler Taveira de Oliveira <euler(at)timbira(dot)com> writes:
> Bruce Momjian wrote:
>> Is this for 8.2?
>>
> This patch "fixes" (reimplements) a feature that was written for 8.2. So
> I think it's a must-fix. That patch is not so huge or invasive.
> Comments?

Exactly how bad could the consequences get if someone sets LC_TIME to a
value not encoding-compatible with the database encoding? One of the
reasons LC_MESSAGES is superuser-only is that you can PANIC the backend
by choosing an incompatible value --- will that happen now for LC_TIME
too?

I think it might be OK, because the reason for the PANIC in the bogus
message case is that the encoding-violation error happens recursively
inside error processing, and that shouldn't need to happen here. But
one thing we'll need to be damn sure of is that control can't get into
elog.c while we've got LC_TIME set to a non-C value, else the same
recursion scenario could occur due to log_line_prefix expansion.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bernd Helmle 2006-11-24 16:39:08 Weird behavior in psql with \copy
Previous Message Bruce Momjian 2006-11-24 15:27:10 Re: Avg performance for int8/numeric