Skip site navigation (1) Skip section navigation (2)

pgsql: Replace empty locale name with implied value in CREATEDATABASE

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Replace empty locale name with implied value in CREATEDATABASE
Date: 2012-03-26 01:47:30
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-committerspgsql-hackers
Replace empty locale name with implied value in CREATE DATABASE and initdb.

setlocale() accepts locale name "" as meaning "the locale specified by the
process's environment variables".  Historically we've accepted that for
Postgres' locale settings, too.  However, it's fairly unsafe to store an
empty string in a new database's pg_database.datcollate or datctype fields,
because then the interpretation could vary across postmaster restarts,
possibly resulting in index corruption and other unpleasantness.

Instead, we should expand "" to whatever it means at the moment of calling
CREATE DATABASE, which we can do by saving the value returned by

For consistency, make initdb set up the initial lc_xxx parameter values the
same way.  initdb was already doing the right thing for empty locale names,
but it did not replace non-empty names with setlocale results.  On a
platform where setlocale chooses to canonicalize the spellings of locale
names, this would result in annoying inconsistency.  (It seems that popular
implementations of setlocale don't do such canonicalization, which is a
pity, but the POSIX spec certainly allows it to be done.)  The same risk
of inconsistency leads me to not venture back-patching this, although it
could certainly be seen as a longstanding bug.

Per report from Jeff Davis, though this is not his proposed patch.



Modified Files
src/backend/commands/dbcommands.c |    9 +++-
src/backend/utils/adt/pg_locale.c |   34 ++++++++++----
src/bin/initdb/initdb.c           |   86 +++++++++++++++++++++++++------------
src/include/utils/pg_locale.h     |    2 +-
4 files changed, 90 insertions(+), 41 deletions(-)


pgsql-hackers by date

Next:From: Joachim WielandDate: 2012-03-26 02:50:51
Subject: Re: patch for parallel pg_dump
Previous:From: Tom LaneDate: 2012-03-25 21:14:48
Subject: Re: COPY / extend ExclusiveLock

pgsql-committers by date

Next:From: Tom LaneDate: 2012-03-26 03:18:08
Subject: pgsql: Fix COPY FROM for null marker strings that correspond toinvalid
Previous:From: Tom LaneDate: 2012-03-24 20:22:54
Subject: pgsql: Fix planner's handling of outer PlaceHolderVars withinsubquerie

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group