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