Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers