On 25.01.2012 15:29, Jim Mlodgenski wrote:
> On Tue, Jan 24, 2012 at 7:38 AM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com> wrote:
>> There's one little problem remaining with this, which is what to do if the
>> message is in a different encoding than used by the client? That's not a new
>> problem, we have the same problem with any string GUC, if you do "SHOW
>> <setting>". We restricted application_name to ASCII characters, which is an
>> obvious way to avoid the problem, but I think it would be a shame to
>> restrict this to ASCII-only.
> Isn't that an issue for the administrator understanding his audience.
> Maybe some additional documentation explaining the encoding issue?
The thing is, there's currently no encoding conversion happening, so if
you have one database in LATIN1 encoding and another in UTF-8, for
example, whatever you put in your postgresql.conf is going to be wrong
for one database. I'm happy to just document the issue for per-database
messages, "ALTER DATABASE ... SET welcome_message", the encoding used
there need to match the encoding of the database, or it's displayed as
garbage. But what about per-user messages, when the user has access to
several databases, or postgresql.conf?
For postgresql.conf I think we could make a rule that it's always in
UTF-8. We haven't had to take a stance on the encoding used in
postgresql.conf before, but IMHO UTF-8 only would be quite reasonable.
We already have a problem there if for example you have two database
with different encodings, a schema with non-ascii characters in it, and
you try to put that schema in search_path in postgresql.conf. That's
such a rare situation that we haven't heard any complaints, but it's not
so unreasonable for welcome_message.
That still leaves the problem with per-user messages, though. We've
managed to dodge the encoding issue in shared catalogs this far. It
would be pretty hard to enforce any given encoding there, I think.
Perhaps we could just document that, and advice to create per-database
and per-user settings in that case.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
