Re: ALTER EXTENSION UPGRADE, v3

Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>>> I can already hear people wanting version aliases instead.  We could
>>> support e.g. 4 or 5 aliases like 'stable', 'support', 'alpha', 'beta'
>>> and maybe 'experimental'.  Then rather than defining "current_version"
>>> authors would define any set of those keywords here, and CREATE
>>> EXTENSION and ALTER EXTENSION would by default only care for
>>> resp. 'stable' and 'support'.

>> Hmm.  That might be worth doing, but let's leave it for later when we
>> find out how much demand there really is.  It does strike me that what
>> we ought to call the default-version parameter is just "default", since
>> that would fit in reasonably well with such an extension later.

> We could go as far as not requiring anything but considering any unknown
> parameter as a version alias, or setup a GUC placeholder so that the
> control file parsing is able to read version.defaut = '1.0' and others.

I think having the code do something with "any unknown parameter" is a
seriously bad idea: it removes a useful error check, and it opens a
strong likelihood that different versions of PG will interpret the same
control file differently.

After a bit of reflection I think we should stick with "default_version"
as the parameter name in 9.1.  If we want to open it up to allowing
arbitrary version aliases later, we can let it accept "xxx_version" as
defining an alias "xxx".  That seems a lot safer than interpreting any
old unrecognized parameter name as a version alias.


> Then we would just document what the default aliases are used by the
> commands CREATE EXTENSION and ALTER EXTENSION UPDATE TO.  The big
> advantage of doing so is that it's then easy for extension authors to
> manage EOL.

>   ALTER EXTENSION foo UPDATE;
>   ERROR:  there's no 'support' version available from version 1.2.3

> Then you have to write ALTER EXTENSION foo UPDATE TO '2.0' or even
> UPDATE TO 'stable', and you realise it's a "major" upgrade, so you need
> to recheck the extension release notes etc.

Uh, not sure how you're envisioning that working?  If it fails to find
an upgrade script path from the current version to whatever is default,
it will still fail to find any path after you explicitly tell it you
want to upgrade to that version.
        regards, tom lane