> 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.
Well, that makes solution (D) a lot more viable then.
> 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.
I could do it, given an extension upgrade script which could run
PL/pgSQL code. That is, I could write a script which finds all indexes
dependant on a particular data type and reindex them.
So I disagree that it can't be solved. It just can't be solved *by
pg_upgrade*.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
