Euler Taveira de Oliveira <euler@timbira.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
