On Sun, Apr 24, 2011 at 10:46 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Daniele Varrazzo <daniele.varra...@gmail.com> writes: >> On Thu, Apr 21, 2011 at 4:16 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> If you did not actually change the contents of the install script, you >>> should not change its version number either. > >> Sorry, I'm not entirely convinced. If I release an extension 1.0, then >> find a bug in the C code and fix it in 1.0.1, arguably "make install" >> will put the .so in the right place and the 1.0.1 code will be picked >> up by new sessions. But pg_extension still knows 1.0 as extension >> version, and ALTER EXTENSION ... UPGRADE fails because no update path >> is knows. > > If you didn't change the install script then it's not necessary to > execute ALTER EXTENSION ... UPGRADE. You seem to be assuming that the > pg_extensions catalog has to reflect the bug fix level of an extension, > but that is *not* the intention. If it did reflect that, you'd need > N times as many upgrade scripts, most of them identical, to deal with > updating from different bug fix levels of the prior version.
Yes, I was assuming that the pg_extension catalog should have included the bug fix level, and I noticed the explosion of upgrade paths required. > IMO it'd be better if the bug fix level was tracked outside the > database, for instance via an RPM package version/release number. > I'm not sure whether PGXN has anything for that at the moment. PGXN requires a version for the extension, possibly including the patchlevel (well, actually forcing a patchlevel, as per semver spec), and I/David/probably everybody else were thinking that such version ought to be the same specified in the .control file. I see that a better guideline would be to have '1.0' specified in the control and '1.0.X' in the metadata submitted on PGXN, which I think is not currently the case - see for example http://api.pgxn.org/src/pair/pair-0.1.2/pair.control -- Daniele -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
