Re: More message encoding woes

Heikki Linnakangas wrote:
> One idea is to extract the encoding from LC_MESSAGES. Then call 
> pg_get_encoding_from_locale() on that and check that it matches 
> server_encoding. If it does, great, pass it to 
> bind_textdomain_codeset(). If it doesn't, throw an error.

I tried to implement this but it gets complicated. First of all, we can 
only throw an error when lc_messages is set interactively. If it's set 
in postgresql.conf, it might be valid for some databases but not for 
others with different encoding. And that makes per-user lc_messages 
setting quite hard too.

Another complication is what to do if e.g. plpgsql or a 3rd party module 
have called pg_bindtextdomain, when lc_messages=C and we don't yet know 
the system name for the database encoding, and you later set 
lc_messages='fi_FI.iso8859-1', in a latin1 database. In order to 
retroactively set the codeset, we'd have to remember all the calls to 
pg_bindtextdomain. Not impossible, for sure, but more work.

I'm leaning towards the idea of trying out all the spellings of the 
database encoding we have in encoding_match_list. That gives the best 
user experience, as it just works, and it doesn't seem that complicated.

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