Re: ALTER EXTENSION UPGRADE, v3 - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: ALTER EXTENSION UPGRADE, v3
Date
Msg-id m27hd6a2zk.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Re: ALTER EXTENSION UPGRADE, v3  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: ALTER EXTENSION UPGRADE, v3  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:
>> 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.
>
> Hmm.  To make that work, we'd have to have ALTER EXTENSION UPDATE use a
> different default version name from what CREATE EXTENSION uses (unless

Yes.  I see that as a good feature to have.  stable and support looks
like good default aliases for me, but again, IANANS (native speaker).

> you're willing to also break use of CREATE EXTENSION without an explicit
> target version).  I was intending to have "default_version" identify the
> default target for both cases.  While we could have different parameters
> for the two cases, I think it would mostly just cause confusion.

I happen to think it would avoid too much confusion myself.  There's a
semantic difference here, that's not just playing with keywords.  And
we're adding nice error checks to help stay on the safe side.

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Careful PL/Perl Release Not Required
Next
From: Tom Lane
Date:
Subject: Re: ALTER EXTENSION UPGRADE, v3