Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit70b9b9b

Browse files
committed
Change initdb and CREATE DATABASE to actively reject attempts to create
databases with encodings that are incompatible with the server's LC_CTYPElocale, when we can determine that (which we can on most modern platforms,I believe). C/POSIX locale is compatible with all encodings, of course,so there is still some usefulness to CREATE DATABASE's ENCODING option,but this will insulate us against all sorts of recurring complaintscaused by mismatched settings.I moved initdb's existing LC_CTYPE-to-encoding mapping knowledge intoa new src/port/ file so it could be shared by CREATE DATABASE.
1 parentae0b90f commit70b9b9b

File tree

8 files changed

+400
-263
lines changed

8 files changed

+400
-263
lines changed

‎doc/src/sgml/charset.sgml

Lines changed: 35 additions & 22 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
<!-- $PostgreSQL: pgsql/doc/src/sgml/charset.sgml,v 2.83 2007/04/15 10:56:25 ishii Exp $ -->
1+
<!-- $PostgreSQL: pgsql/doc/src/sgml/charset.sgml,v 2.84 2007/09/28 22:25:49 tgl Exp $ -->
22

33
<chapter id="charset">
44
<title>Localization</>
@@ -249,7 +249,7 @@ initdb --locale=sv_SE
249249
<title>Problems</>
250250

251251
<para>
252-
If locale support doesn't workin spite of the explanation above,
252+
If locale support doesn't workaccording to the explanation above,
253253
check that the locale support in your operating system is
254254
correctly configured. To check what locales are installed on your
255255
system, you can use the command <literal>locale -a</literal> if
@@ -301,7 +301,8 @@ initdb --locale=sv_SE
301301

302302
<para>
303303
The character set support in <productname>PostgreSQL</productname>
304-
allows you to store text in a variety of character sets, including
304+
allows you to store text in a variety of character sets (also called
305+
encodings), including
305306
single-byte character sets such as the ISO 8859 series and
306307
multiple-byte character sets such as <acronym>EUC</> (Extended Unix
307308
Code), UTF-8, and Mule internal code. All supported character sets
@@ -314,6 +315,20 @@ initdb --locale=sv_SE
314315
databases each with a different character set.
315316
</para>
316317

318+
<para>
319+
An important restriction, however, is that each database character set
320+
must be compatible with the server's <envar>LC_CTYPE</> setting.
321+
When <envar>LC_CTYPE</> is <literal>C</> or <literal>POSIX</>, any
322+
character set is allowed, but for other settings of <envar>LC_CTYPE</>
323+
there is only one character set that will work correctly.
324+
Since the <envar>LC_CTYPE</> setting is frozen by <command>initdb</>, the
325+
apparent flexibility to use different encodings in different databases
326+
of a cluster is more theoretical than real, except when you select
327+
<literal>C</> or <literal>POSIX</> locale (thus disabling any real locale
328+
awareness). It is likely that these mechanisms will be revisited in future
329+
versions of <productname>PostgreSQL</productname>.
330+
</para>
331+
317332
<sect2 id="multibyte-charset-supported">
318333
<title>Supported Character Sets</title>
319334

@@ -716,7 +731,8 @@ initdb -E EUC_JP
716731
</para>
717732

718733
<para>
719-
You can create a database with a different character set:
734+
If you have selected <literal>C</> or <literal>POSIX</> locale,
735+
you can create a database with a different character set:
720736

721737
<screen>
722738
createdb -E EUC_KR korean
@@ -731,7 +747,7 @@ CREATE DATABASE korean WITH ENCODING 'EUC_KR';
731747
</programlisting>
732748

733749
The encoding for a database is stored in the system catalog
734-
<literal>pg_database</literal>. You can seethat by using the
750+
<literal>pg_database</literal>. You can seeit by using the
735751
<option>-l</option> option or the <command>\l</command> command
736752
of <command>psql</command>.
737753

@@ -756,26 +772,23 @@ $ <userinput>psql -l</userinput>
756772

757773
<important>
758774
<para>
759-
Although you can specify any encoding you want for a database, it is
760-
unwise to choose an encoding that is not what is expected by the locale
761-
you have selected. The <literal>LC_COLLATE</literal> and
762-
<literal>LC_CTYPE</literal> settings imply a particular encoding,
763-
and locale-dependent operations (such as sorting) are likely to
764-
misinterpret data that is in an incompatible encoding.
765-
</para>
766-
767-
<para>
768-
Since these locale settings are frozen by <command>initdb</>, the
769-
apparent flexibility to use different encodings in different databases
770-
of a cluster is more theoretical than real. It is likely that these
771-
mechanisms will be revisited in future versions of
772-
<productname>PostgreSQL</productname>.
775+
On most modern operating systems, <productname>PostgreSQL</productname>
776+
can determine which character set is implied by an <envar>LC_CTYPE</>
777+
setting, and it will enforce that only the correct database encoding is
778+
used. On older systems it is your responsibility to ensure that you use
779+
the encoding expected by the locale you have selected. A mistake in
780+
this area is likely to lead to strange misbehavior of locale-dependent
781+
operations such as sorting.
773782
</para>
774783

775784
<para>
776-
One way to use multiple encodings safely is to set the locale to
777-
<literal>C</> or <literal>POSIX</> during <command>initdb</>, thus
778-
disabling any real locale awareness.
785+
<productname>PostgreSQL</productname> will allow superusers to create
786+
databases with <literal>SQL_ASCII</> encoding even when
787+
<envar>LC_CTYPE</> is not <literal>C</> or <literal>POSIX</>. As noted
788+
above, <literal>SQL_ASCII</> does not enforce that the data stored in
789+
the database has any particular encoding, and so this choice poses risks
790+
of locale-dependent misbehavior. Using this combination of settings is
791+
deprecated and may someday be forbidden altogether.
779792
</para>
780793
</important>
781794
</sect2>

‎doc/src/sgml/ref/create_database.sgml

Lines changed: 18 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
11
<!--
2-
$PostgreSQL: pgsql/doc/src/sgml/ref/create_database.sgml,v 1.47 2007/01/31 23:26:03 momjian Exp $
2+
$PostgreSQL: pgsql/doc/src/sgml/ref/create_database.sgml,v 1.48 2007/09/28 22:25:49 tgl Exp $
33
PostgreSQL documentation
44
-->
55

@@ -107,7 +107,8 @@ CREATE DATABASE <replaceable class="PARAMETER">name</replaceable>
107107
to use the default encoding (namely, the encoding of the
108108
template database). The character sets supported by the
109109
<productname>PostgreSQL</productname> server are described in
110-
<xref linkend="multibyte-charset-supported">.
110+
<xref linkend="multibyte-charset-supported">. See below for
111+
additional restrictions.
111112
</para>
112113
</listitem>
113114
</varlistentry>
@@ -178,6 +179,21 @@ CREATE DATABASE <replaceable class="PARAMETER">name</replaceable>
178179
See <xref linkend="manage-ag-templatedbs"> for more information.
179180
</para>
180181

182+
<para>
183+
Any character set encoding specified for the new database must be
184+
compatible with the server's <envar>LC_CTYPE</> locale setting.
185+
If <envar>LC_CTYPE</> is <literal>C</> (or equivalently
186+
<literal>POSIX</>), then all encodings are allowed, but for other
187+
locale settings there is only one encoding that will work properly,
188+
and so the apparent freedom to specify an encoding is illusory if
189+
you didn't initialize the database cluster in <literal>C</> locale.
190+
<command>CREATE DATABASE</> will allow superusers to specify
191+
<literal>SQL_ASCII</> encoding regardless of the locale setting,
192+
but this choice is deprecated and may result in misbehavior of
193+
character-string functions if data that is not encoding-compatible
194+
with the locale is stored in the database.
195+
</para>
196+
181197
<para>
182198
The <literal>CONNECTION LIMIT</> option is only enforced approximately;
183199
if two new sessions start at about the same time when just one

‎src/Makefile.global.in

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
11
# -*-makefile-*-
2-
# $PostgreSQL: pgsql/src/Makefile.global.in,v 1.238 2007/08/20 08:53:12 petere Exp $
2+
# $PostgreSQL: pgsql/src/Makefile.global.in,v 1.239 2007/09/28 22:25:49 tgl Exp $
33

44
#------------------------------------------------------------------------------
55
# All PostgreSQL makefiles include this file and use the variables it sets,
@@ -423,7 +423,7 @@ endif
423423
#
424424
# substitute implementations of C library routines (see src/port/)
425425

426-
LIBOBJS = @LIBOBJS@ copydir.o dirmod.o exec.o noblock.o path.o pipe.o pgsleep.o pgstrcasecmp.o qsort.o qsort_arg.o sprompt.o thread.o
426+
LIBOBJS = @LIBOBJS@
427427

428428
LIBS := -lpgport$(LIBS)
429429
# add location of libpgport.a to LDFLAGS

‎src/backend/commands/dbcommands.c

Lines changed: 29 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -13,13 +13,14 @@
1313
*
1414
*
1515
* IDENTIFICATION
16-
* $PostgreSQL: pgsql/src/backend/commands/dbcommands.c,v 1.198 2007/09/03 18:46:29 tgl Exp $
16+
* $PostgreSQL: pgsql/src/backend/commands/dbcommands.c,v 1.199 2007/09/28 22:25:49 tgl Exp $
1717
*
1818
*-------------------------------------------------------------------------
1919
*/
2020
#include"postgres.h"
2121

2222
#include<fcntl.h>
23+
#include<locale.h>
2324
#include<unistd.h>
2425
#include<sys/stat.h>
2526

@@ -96,6 +97,7 @@ createdb(const CreatedbStmt *stmt)
9697
constchar*dbtemplate=NULL;
9798
intencoding=-1;
9899
intdbconnlimit=-1;
100+
intctype_encoding;
99101

100102
/* Extract options from the statement node tree */
101103
foreach(option,stmt->options)
@@ -254,6 +256,32 @@ createdb(const CreatedbStmt *stmt)
254256
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
255257
errmsg("invalid server encoding %d",encoding)));
256258

259+
/*
260+
* Check whether encoding matches server locale settings. We allow
261+
* mismatch in two cases:
262+
*
263+
* 1. ctype_encoding = SQL_ASCII, which means either that the locale
264+
* is C/POSIX which works with any encoding, or that we couldn't determine
265+
* the locale's encoding and have to trust the user to get it right.
266+
*
267+
* 2. selected encoding is SQL_ASCII, but only if you're a superuser.
268+
* This is risky but we have historically allowed it --- notably, the
269+
* regression tests require it.
270+
*
271+
* Note: if you change this policy, fix initdb to match.
272+
*/
273+
ctype_encoding=pg_get_encoding_from_locale(NULL);
274+
275+
if (!(ctype_encoding==encoding||
276+
ctype_encoding==PG_SQL_ASCII||
277+
(encoding==PG_SQL_ASCII&&superuser())))
278+
ereport(ERROR,
279+
(errmsg("encoding %s does not match server's locale %s",
280+
pg_encoding_to_char(encoding),
281+
setlocale(LC_CTYPE,NULL)),
282+
errdetail("The server's LC_CTYPE setting requires encoding %s.",
283+
pg_encoding_to_char(ctype_encoding))));
284+
257285
/* Resolve default tablespace for new database */
258286
if (dtablespacename&&dtablespacename->arg)
259287
{

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp