pgsql: Fix pg_extension_config_dump() to handle update cases more sanel - Mailing list pgsql-committers

From Tom Lane
Subject pgsql: Fix pg_extension_config_dump() to handle update cases more sanel
Date
Msg-id E1Tlnj2-0000IJ-EI@gemulon.postgresql.org
Whole thread Raw
List pgsql-committers
Fix pg_extension_config_dump() to handle update cases more sanely.

If pg_extension_config_dump() is executed again for a table already listed
in the extension's extconfig, the code was blindly making a new array entry.
This does not seem useful.  Fix it to replace the existing array entry
instead, so that it's possible for extension update scripts to alter the
filter conditions for configuration tables.

In addition, teach ALTER EXTENSION DROP TABLE to check for an extconfig
entry for the target table, and remove it if present.  This is not a 100%
solution because it's allowed for an extension update script to just
summarily DROP a member table, and that code path doesn't go through
ExecAlterExtensionContentsStmt.  We could probably make that case clean
things up if we had to, but it would involve sticking a very ugly wart
somewhere in the guts of dependency.c.  Since on the whole it seems quite
unlikely that extension updates would want to remove pre-existing
configuration tables, making the case possible with an explicit command
seems sufficient.

Per bug #7756 from Regina Obe.  Back-patch to 9.1 where extensions were
introduced.

Branch
------
REL9_1_STABLE

Details
-------
http://git.postgresql.org/pg/commitdiff/17a71067d03edfc7a0eddb5bff42f48fb1855d82

Modified Files
--------------
doc/src/sgml/extend.sgml         |   12 ++
src/backend/commands/extension.c |  237 ++++++++++++++++++++++++++++++++++++--
2 files changed, 239 insertions(+), 10 deletions(-)


pgsql-committers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: pgsql: Fix recycling of WAL segments after changing recovery target tim
Next
From: Tom Lane
Date:
Subject: pgsql: Fix pg_extension_config_dump() to handle update cases more sanel