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