Tom Lane wrote:
> What we need is an API equivalent to "iconv --list", but I'm not seeing
> one :-(.
There's also "locale -m". Looking at the implementation of that, it just
lists what's in /usr/share/i18n/charmaps. Not too portable either..
> Do we need to go so far as to try to run that program?
> Its output format is poorly standardized, among other problems ...
And doing that at every backend startup is too slow.
I would be happy to just revert to English if the OS doesn't recognize
the name we use for the encoding. What sucks about that most is that the
user has no way to specify the right encoding name even if he knows it.
I don't think we want to introduce a new GUC for that.
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.
It stretches the conventional meaning LC_MESSAGES/LC_CTYPE a bit, since
LC_CTYPE usually specifies the codeset to use, but I think it's quite
intuitive.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com