Tom Lane <t...@sss.pgh.pa.us> writes: > However, the only way I can see to fix this "automatically" is to have > the makefiles propagate PG_VERSION_NUM (or one of the other values set > by configure) into generated control files.
Ah, somewhat like what I was asked to remove from the patch, right? -EXTVERSION = $(VERSION) > I don't think that's what > we want either. If we do that, then people are going to be forced to > go through an ALTER EXTENSION UPGRADE cycle whether or not anything > actually changed in the extension's SQL definitions. We really only > want the extension's SQL version to change when there was a meaningful > change in the SQL commands. Well that's just a facility, and very useful for people that have a Make variable where the extension's version is already held. This problem of having a VERSION that moves when the extension possibly didn't change seems pretty specific to PostgreSQL, not typical for extensions authors. > I'm not sure that I see a better answer than hand-maintained version > numbers in each extension SQL file. But if that's where we're going, > they should be in the SQL files, not in either the Makefiles or control > files. You lost me. Are you wanting extension authors to maintain meta data in the SQL script, with some new syntax support, or maybe from calling a function? How do you think this will play with upgrading? That doesn't sound any simpler to me. The whole goal of the control file is to be able to register the extension in the catalog and get an OID there to manage the dependencies (so that we get a single command per extension in pg_dump output). The first design proposed an SQL command to fill in the catalog, but that command must be separate from what the DBA will have to type in to have the server execute the script, so this idea has been beaten by the control file idea (thanks goes to Heikki). Now, we could go with the current patch for starters and add some facilities around 9.2 when we have experienced the maintenance burden. And extension authors will probably be asking for some more facilities too, by then. 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
