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

pgsql: Accept a non-existent value in "ALTER USER/DATABASE SET ..."com

From: Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)fi>
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Accept a non-existent value in "ALTER USER/DATABASE SET ..."com
Date: 2012-01-30 09:54:35
Message-ID: E1RrnwZ-0000wy-7X@gemulon.postgresql.org (view raw or flat)
Thread:
Lists: pgsql-committers
Accept a non-existent value in "ALTER USER/DATABASE SET ..." command.

When default_text_search_config, default_tablespace, or temp_tablespaces
setting is set per-user or per-database, with an "ALTER USER/DATABASE SET
..." statement, don't throw an error if the text search configuration or
tablespace does not exist. In case of text search configuration, even if
it doesn't exist in the current database, it might exist in another
database, where the setting is intended to have its effect. This behavior
is now the same as search_path's.

Tablespaces are cluster-wide, so the same argument doesn't hold for
tablespaces, but there's a problem with pg_dumpall: it dumps "ALTER USER
SET ..." statements before the "CREATE TABLESPACE" statements. Arguably
that's pg_dumpall's fault - it should dump the statements in such an order
that the tablespace is created first and then the "ALTER USER SET
default_tablespace ..." statements after that - but it seems better to be
consistent with search_path and default_text_search_config anyway. Besides,
you could still create a dump that throws an error, by creating the
tablespace, running "ALTER USER SET default_tablespace", then dropping the
tablespace and running pg_dumpall on that.

Backpatch to all supported versions.

Branch
------
REL8_3_STABLE

Details
-------
http://git.postgresql.org/pg/commitdiff/483c8ce2a4296197f377e33b3a38a219cfcddb15

Modified Files
--------------
src/backend/commands/tablespace.c  |   23 ++++++++++++++++++++---
src/backend/utils/cache/ts_cache.c |   20 +++++++++++++++++++-
2 files changed, 39 insertions(+), 4 deletions(-)

pgsql-committers by date

Next:From: Robert HaasDate: 2012-01-30 14:12:17
Subject: Re: pgsql: Resolve timing issue with logging locks for Hot Standby.
Previous:From: Simon RiggsDate: 2012-01-30 09:13:04
Subject: Re: pgsql: Resolve timing issue with logging locks for Hot Standby.

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