From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: ALTER EXTENSION UPGRADE, v3 |
Date: | 2011-02-03 23:29:14 |
Message-ID: | 4D4B3A4A.2060807@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-02-03 23:29:54 | Re: [HACKERS] Slow count(*) again... |
Previous Message | Mladen Gogala | 2011-02-03 23:25:02 | Re: [HACKERS] Slow count(*) again... |