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