From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jim Mlodgenski <jimmy76@gmail.com>
Cc: Fujii Masao <masao.fujii@gmail.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Client Messages
Date: Thu, 26 Jan 2012 20:58:58 +0200
Message-ID: <4F21A272.3000703@enterprisedb.com> (raw)
In-Reply-To: <4484.1327591916@sss.pgh.pa.us>
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>
<4F21102A.2080506@enterprisedb.com>
<4484.1327591916@sss.pgh.pa.us>
On 26.01.2012 17:31, Tom Lane wrote:
> Heikki Linnakangas<heikki.linnakangas@enterprisedb.com> writes:
>> 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?
>
> I've not looked at the patch, but what exactly will happen if the string
> has the wrong encoding?
You get an incorrectly encoded string, ie. garbage, in your console,
when you log in with psql.
You can also use current_setting() to copy the incorrectly-encoded
string elsewhere in the system. If you insert it into a table and run
pg_dump, I think the dump might not be restorable. That's a bit of a
stretch, perhaps, but it would be nice to avoid that.
BTW, you can already do that if you set e.g default_text_search_config
to something non-ASCII in postgresql.conf. Or if you do it with
search_path, you get a warning at login. For example, I did "ALTER USER
foouser set search_path ='kääk';" in a LATIN1 database, and then
connected to a UTF-8 database and got:
$ ~/pgsql.master/bin/psql postgres foouser
WARNING: invalid value for parameter "search_path": ""k��k""
DETAIL: schema "k��k" does not exist
psql (9.2devel)
Type "help" for help.
(in case that didn't get across right, I set the search_path to a string
containing two a-with-umlauts, and in the warning, they got replaced
with question marks with inverse colors, which is apparently a character
that the console uses to display bytes that are not valid UTF-8).
The problem with welcome_message would look just like that. No-one is
likely to run into that with search_path, but it's quite reasonable and
expected to use your native language in a welcome message.
> The idea that occurs to me is to have the code that uses the GUC do a
> verify_mbstr(noerror) on it, and silently ignore it if it doesn't pass
> (maybe with a LOG message). This would have to be documented of course,
> but it seems better than the potential consequences of trying to send a
> wrongly-encoded string.
Hmm, fine with me. It would be nice to plug the hole that these bogus
characters can leak elsewhere into the system through current_setting,
though. Perhaps we could put the verify_mbstr() call somewhere in guc.c,
to forbid incorrectly encoded characters from being stored in the guc
variable in the first place.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: heikki.linnakangas@enterprisedb.com, tgl@sss.pgh.pa.us, jimmy76@gmail.com, masao.fujii@gmail.com
Subject: Re: Client Messages
In-Reply-To: <4F21A272.3000703@enterprisedb.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox