Re: More message encoding woes

Peter Eisentraut wrote:
> On Tuesday 07 April 2009 13:09:42 Heikki Linnakangas wrote:
>> Patch attached. Instead of checking for LC_CTYPE == C, I'm checking
>> "pg_get_encoding_from_locale(NULL) == encoding" which is more close to
>> what we actually want. The downside is that
>> pg_get_encoding_from_locale(NULL) isn't exactly free, but the upside is
>> that we don't need to keep this in sync with the rules we have in CREATE
>> DATABASE that enforce that locale matches encoding.
> 
> I would have figured we can skip this whole thing when LC_CTYPE != C, because 
> it should be guaranteed that LC_CTYPE matches the database encoding in this 
> case, no?

Yes, except if pg_get_encoding_from_locale() couldn't figure out what PG 
encoding LC_CTYPE corresponds to. We let CREATE DATABASE to go ahead in 
that case, trusting that the user knows what he's doing. I suppose we 
can extend that trust to this case too, and assume that the encoding of 
LC_CTYPE actually matches the database encoding.

Or if the encoding is UTF-8 and you're running on Windows, although on 
Windows we want to always call bind_textdomain_codeset(). Or if the 
database encoding is SQL_ASCII, although in that case we don't want to 
call bind_textdomain_codeset() either.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com