Re: client_lc_messages

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: client_lc_messages
Date: 2009-10-23 16:02:28
Message-ID: 11456.1256313748@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> So we'd go with a single setting to define language, which would be the
> current lc_messages, and two new settings, say translate_log_messages
> and translate_client_messages, the latter being USERSET.

> Does that sound reasonable?

How do we get to the point where individual users can choose their
message language, though? If LC_MESSAGES stays as SUSET then you
haven't really made matters better for anybody.

With the above infrastructure, we could get there if there were a way to
say "LC_MESSAGES is USERSET if translate_log_messages is OFF", but there
isn't and I doubt it would be a good idea to try to make it work like
that.

Maybe we should stick to the original design and just document that
you'll take a big performance hit if the settings are different and
both not "C". And of course make sure we avoid the performance hit
otherwise.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2009-10-23 16:05:15 Re: plpgsql EXECUTE will not set FOUND
Previous Message Simon Riggs 2009-10-23 16:02:24 Re: Using views for row-level access control is leaky