Josh Berkus <j...@agliodbs.com> writes:
> (D) Requires a series of ordered upgrade scripts in sortable version
> numbering, each of which gets applied in order between the two versions.
> This initially seems like the most attractive option -- and is the one
> used by dozens of popular open source web applications -- but has some
> major roadblocks for us. First, it requires module authors to subscribe
> to a uniform sortable versions scheme (which isn't a bad thing, the
> users would certainly appreciate it, and PGXN is liable to enforce this
> anyway). Second and much more substantially, .so's installed for later
> versions might be incompatible with intermediate upgrade scripts, and
> intermediate .so's are unlikely to be present.
FWIW, I think that last objection is bogus. There's no reason that an
extension author can't leave dummy C functions in his code to support
obsolete CREATE FUNCTION calls. (As an example, I added one to
Alexander Korotkov's recent pg_trgm patch. It consists of 10 lines of
boilerplate code, and could have been less if I'd used a quick and dirty
elog() instead of ereport().) This is certainly a lot less of a problem
than the difficulties with the other approaches.
I think some of your objections to the pg_upgrade approach are equally
bogus. In particular, I don't believe any of these approaches will
usefully serve cases where indexes have to be rebuilt to be compatible
with a new .so. Those indexes won't all be in the same database, and
even if they were, no simple SQL script is going to be able to find
them. If an extension author wants to break on-disk compatibility, it's
going to be just as unfriendly to his users as such a break in the core
database will be, ie, they're going to have to do dump and reload. The
extension mechanism can't be expected to solve that.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
