diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2016-09-11 14:15:07 -0400 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2016-09-11 14:15:07 -0400 |
commit | 40b449ae84dcf71177d7749a7b0c582b64dc15f0 (patch) | |
tree | 24dbf3ed8dc091ff503c571938ab3ac4a58f9cd3 /src/backend/access/transam/commit_ts.c | |
parent | 28e5e5648cc3666537c393b2636c4aa34fdb22c1 (diff) | |
download | postgresql-40b449ae84dcf71177d7749a7b0c582b64dc15f0.tar.gz postgresql-40b449ae84dcf71177d7749a7b0c582b64dc15f0.zip |
Allow CREATE EXTENSION to follow extension update paths.
Previously, to update an extension you had to produce both a version-update
script and a new base installation script. It's become more and more
obvious that that's tedious, duplicative, and error-prone. This patch
attempts to improve matters by allowing the new base installation script
to be omitted. CREATE EXTENSION will install a requested version if it
can find a base script and a chain of update scripts that will get there.
As in the existing update logic, shorter chains are preferred if there's
more than one possibility, with an arbitrary tie-break rule for chains
of equal length.
Also adjust the pg_available_extension_versions view to show such versions
as installable.
While at it, refactor the code so that CASCADE processing works for
extensions requested during ApplyExtensionUpdates(). Without this,
addition of a new requirement in an updated extension would require
creating a new base script, even if there was no other reason to do that.
(It would be easy at this point to add a CASCADE option to ALTER EXTENSION
UPDATE, to allow the same thing to happen during a manually-commanded
version update, but I have not done that here.)
Tom Lane, reviewed by Andres Freund
Discussion: <20160905005919.jz2m2yh3und2dsuy@alap3.anarazel.de>
Diffstat (limited to 'src/backend/access/transam/commit_ts.c')
0 files changed, 0 insertions, 0 deletions