Re: client_lc_messages - Mailing list pgsql-hackers

From Tom Lane
Subject Re: client_lc_messages
Date
Msg-id 11456.1256313748@sss.pgh.pa.us
Whole thread Raw
In response to Re: client_lc_messages  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: plpgsql EXECUTE will not set FOUND
Next
From: Simon Riggs
Date:
Subject: Re: Using views for row-level access control is leaky