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