Tom Lane <tgl@sss.pgh.pa.us> writes:
> 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.
That was my first idea, like I did with upgrade_from_xxx, but though you
wouldn't like it so much, so proposed the version.xxx form instead :)
>> 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.
That's not exactly what happens here. There would be no "support"
version alias in the control file, so no way to upgrade to it, and
"support" would happen to be what ALTER EXTENSION foo UPDATE would
consider when you don't mention explicitly the target version.
However, when you do say that you want to upgrade to '2.0' or to
'stable', now the upgrade script certainly exists and the version alias
too, so that the upgrade is possible. Only explicitly though.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support