|From:||Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||Aidan Van Dyk <aidan(at)highrise(dot)ca>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Robert Haas <robertmhaas(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org|
|Subject:||Re: ALTER EXTENSION UPGRADE, v3|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
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
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
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
|Next Message||Dimitri Fontaine||2011-02-11 20:31:18||Re: ALTER EXTENSION UPGRADE, v3|
|Previous Message||Tom Lane||2011-02-11 20:26:54||Re: Debian readline/libedit breakage|