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
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 |