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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
