1
0
mirror of https://github.com/postgres/postgres.git synced 2025-06-16 06:01:02 +03:00

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).
This commit is contained in:
Tom Lane
2009-11-12 02:46:16 +00:00
parent 19d802767d
commit 8f8a5df694
4 changed files with 44 additions and 36 deletions

View File

@ -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
* 1. locale encoding = SQL_ASCII, which means that the locale is
* C/POSIX which works with any encoding.
*
* 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.
*
* 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.
*
* 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