Re: Client Messages

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