Re: ALTER EXTENSION UPGRADE, v3

Tom Lane <tgl@sss.pgh.pa.us> writes:
> I don't see that this proposal changes anything about that.  It's still
> the case that the underlying .so is tied to a major PG version.  What
> you'll ship is a control file and assorted .sql files that represent the
> user APIs you are interested in supporting on that major PG version.

That's why I proposed that the require control field would contain the
PostgreSQL release against which the extension is built.
 require = 'postgresql-9.0'

Then, we have to separate multi-major version support, that almost all
extensions have, with extension release schedule and extension new major
versions.

My proposal here was to distinguish between a "support" update and a
"stable" update, so that users are warned and helped somehow.

Other than that, I don't see any reason not to rename the extension in
such cases, like we have postgis-1.4 and postgis-1.5.  That's also
another good reason not to use dash as a version separator in upgrade
scripts, too.

Note that debian uses the semicolon to represent epoch, as a way to fix
upgrades that break their sorting rules.  But we don't have no sorting
rules.

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