diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2009-11-12 02:46:16 +0000 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2009-11-12 02:46:16 +0000 |
| commit | 8f8a5df694e7a012dfd762cb74d2083d83cf573b (patch) | |
| tree | 8e5d3ff2b64bb8243238dfc283f9f5b260f191a7 /src/backend/commands/dbcommands.c | |
| parent | 19d802767d7b9c37390c46d337e6558c0b60ea57 (diff) | |
| download | postgresql-8f8a5df694e7a012dfd762cb74d2083d83cf573b.tar.gz postgresql-8f8a5df694e7a012dfd762cb74d2083d83cf573b.zip | |
Make initdb behave sanely when the selected locale has codeset "US-ASCII".
Per discussion, this should result in defaulting to SQL_ASCII encoding.
The original coding could not support that because it conflated selection
of SQL_ASCII encoding with not being able to determine the encoding.
Adjust pg_get_encoding_from_locale()'s API to distinguish these cases,
and fix callers appropriately. Only initdb actually changes behavior,
since the other callers were perfectly content to consider these cases
equivalent.
Per bug #5178 from Boh Yap. Not going to bother back-patching, since
no one has complained before and there's an easy workaround (namely,
specify the encoding you want).
Diffstat (limited to 'src/backend/commands/dbcommands.c')
| -rw-r--r-- | src/backend/commands/dbcommands.c | 20 |
1 files changed, 12 insertions, 8 deletions
diff --git a/src/backend/commands/dbcommands.c b/src/backend/commands/dbcommands.c index 7df44c9ec41..25dc2f58171 100644 --- a/src/backend/commands/dbcommands.c +++ b/src/backend/commands/dbcommands.c @@ -13,7 +13,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/commands/dbcommands.c,v 1.227 2009/10/07 22:14:18 alvherre Exp $ + * $PostgreSQL: pgsql/src/backend/commands/dbcommands.c,v 1.228 2009/11/12 02:46:16 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -334,20 +334,22 @@ createdb(const CreatedbStmt *stmt) * Check whether chosen encoding matches chosen locale settings. This * restriction is necessary because libc's locale-specific code usually * fails when presented with data in an encoding it's not expecting. We - * allow mismatch in three cases: + * allow mismatch in four cases: * - * 1. locale encoding = SQL_ASCII, which means either that the locale is - * C/POSIX which works with any encoding, or that we couldn't determine - * the locale's encoding and have to trust the user to get it right. + * 1. locale encoding = SQL_ASCII, which means that the locale is + * C/POSIX which works with any encoding. * - * 2. selected encoding is SQL_ASCII, but only if you're a superuser. This - * is risky but we have historically allowed it --- notably, the - * regression tests require it. + * 2. locale encoding = -1, which means that we couldn't determine + * the locale's encoding and have to trust the user to get it right. * * 3. selected encoding is UTF8 and platform is win32. This is because * UTF8 is a pseudo codepage that is supported in all locales since it's * converted to UTF16 before being used. * + * 4. selected encoding is SQL_ASCII, but only if you're a superuser. This + * is risky but we have historically allowed it --- notably, the + * regression tests require it. + * * Note: if you change this policy, fix initdb to match. */ ctype_encoding = pg_get_encoding_from_locale(dbctype); @@ -355,6 +357,7 @@ createdb(const CreatedbStmt *stmt) if (!(ctype_encoding == encoding || ctype_encoding == PG_SQL_ASCII || + ctype_encoding == -1 || #ifdef WIN32 encoding == PG_UTF8 || #endif @@ -369,6 +372,7 @@ createdb(const CreatedbStmt *stmt) if (!(collate_encoding == encoding || collate_encoding == PG_SQL_ASCII || + collate_encoding == -1 || #ifdef WIN32 encoding == PG_UTF8 || #endif |