Re: ALTER EXTENSION UPGRADE, v3

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, Robert Haas <robertmhaas(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: ALTER EXTENSION UPGRADE, v3
Date: 2011-02-11 09:38:32
Message-ID: 878vxmlxlz.fsf@2ndQuadrant.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Actually, I was having second thoughts about that while at dinner. What
> is the value of separating the bootstrap-an-extension-from-old-objects
> operation into two steps? It's certainly not convenient for users, and
> I don't see that the intermediate state with an empty extension has any
> redeeming social value for developers either. (If you need such a thing,
> just make an empty creation script.)

The only reason for doing it this way is that we used to only support 1
available version of an extension at a time, and the commands didn't
know zip about versions. Now that you're putting VERSION support into
CREATE and ALTER EXTENSION commands, I agree that a two steps process
here is to reconsider.

> So: let's forget the concept of a special "null version" altogether, at
> least from the user's-eye viewpoint. Instead, the way to bootstrap from
> loose objects is something like
>
> CREATE EXTENSION foo [ VERSION '1.0' ] [ FROM OLD ]
>
> When you specify FROM OLD, this runs foo--1.0.sql instead of foo-1.0.sql
> as it normally would. As before, that script contains ALTER EXTENSION
> ADD commands instead of CREATE commands.

Sounds good. The problem we have here, it seems to me, is that we don't
know what was the previous version of the extension. It certainly
existed, it's just that PostgreSQL does not know about it. That's what
drove me to think about it as a 'FROM NULL' update.

If you buy into the version alias feature, then what we can do here is
supporting any alias as the FROM argument. The control file would then
associate version.whatever = 0.9 and then the file is foo-0.9-1.0.sql in
your example.

The mechanism would be about the exact thing you described, but with
just a useful indirection in between so that you type:

CREATE EXTENSION foo VERSION stable FROM whatever;

If we require those version aliases to be accepted as GUC names I guess
we can bypass quoting them at the SQL level too, right?

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Vitalii Tymchyshyn 2011-02-11 09:44:05 Re: Why we don't want hints Was: Slow count(*) again...
Previous Message Tobias Brox 2011-02-11 09:29:06 Re: Why we don't want hints Was: Slow count(*) again...