Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229])
	by mail.postgresql.org (Postfix) with ESMTP id A3BD351279
	for <pgsql-hackers@postgresql.org>;
	Thu, 26 Jan 2012 04:35:13 -0400 (AST)
Received: from exprod7og116.obsmtp.com ([64.18.2.219])
	by magus.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <heikki.linnakangas@enterprisedb.com>)
	id 1RqKnV-0002io-Nz
	for pgsql-hackers@postgresql.org; Thu, 26 Jan 2012 08:35:13 +0000
Received: from mail-lpp01m020-f172.google.com ([209.85.217.172]) (using TLSv1)
	by exprod7ob116.postini.com ([64.18.6.12]) with SMTP
	ID DSNKTyEQL4vaaP5qGPyo3kbqv21VXf3yrA/f@postini.com;
	Thu, 26 Jan 2012 00:35:09 PST
Received: by lbbgk8 with SMTP id gk8so20583lbb.17
	for <pgsql-hackers@postgresql.org>;
	Thu, 26 Jan 2012 00:34:53 -0800 (PST)
Received: by 10.112.48.65 with SMTP id j1mr274011lbn.76.1327566893797;
	Thu, 26 Jan 2012 00:34:53 -0800 (PST)
Received: from [192.168.1.102] (dsl-hkibrasgw2-ff6cc300-200.dhcp.inet.fi.
	[88.195.108.200])
	by mx.google.com with ESMTPS id is1sm2558571lab.1.2012.01.26.00.34.51
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 26 Jan 2012 00:34:52 -0800 (PST)
Message-ID: <4F21102A.2080506@enterprisedb.com>
Date: Thu, 26 Jan 2012 10:34:50 +0200
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0
MIME-Version: 1.0
To: Jim Mlodgenski <jimmy76@gmail.com>
CC: Fujii Masao <masao.fujii@gmail.com>, pgsql-hackers@postgresql.org
Subject: Re: Client Messages
References: 
 <CAB_5SRdN1_rx0vkoZ8tC9PmcXCiy0QFEs_=vscg-UrFHeJdB=w@mail.gmail.com>
	<CAHGQGwHM=U+Z_4ezO_tcW9bukBV2bdHg0ve3zMExhqZyX3h8ng@mail.gmail.com>
	<4F167E08.9030802@enterprisedb.com>
	<CAB_5SRefrOd4CM8m=snDicCUDU1QAqt2f+3SfT9eV+wPGWS_6A@mail.gmail.com>
	<CAB_5SRd8xxWn5wAJ6iMoQqJQ1Wfqkbeh8Rhex+T8Uc1tHqSqfw@mail.gmail.com>
	<4F1EA62C.8010203@enterprisedb.com>
	<CAB_5SRc3LX3hhN3Qm380VaGkq_Eh8xRz+nriPf1va51uYAQH7w@mail.gmail.com>
In-Reply-To: 
 <CAB_5SRc3LX3hhN3Qm380VaGkq_Eh8xRz+nriPf1va51uYAQH7w@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pg-Spam-Score: -4.2 (----)
X-Archive-Number: 201201/1480
X-Sequence-Number: 202067

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