Re: client_lc_messages

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: client_lc_messages
Дата
Msg-id 11456.1256313748@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: client_lc_messages  (Alvaro Herrera <alvherre@commandprompt.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: plpgsql EXECUTE will not set FOUND
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Using views for row-level access control is leaky