On Thu, Feb 17, 2011 at 9:13 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > I wrote: >> Robert Haas <robertmh...@gmail.com> writes: >>> I think we should try to make the state match as closely as possible, >>> no matter how you got there. Otherwise, I think we're storing up a >>> host of future pain for ourselves. > >> Well, if you're willing to hold your nose for the "UPDATE pg_proc" hack, >> we can make it so. > > I believe I've now fixed all the discrepancies between fresh installs > and 9.0 updates of contrib modules, except for these: > > 1. citext COLLATABLE option (see adjacent thread) > > 2. intarray and tsearch2 use some core support functions in their > GIN opclasses, and those support functions changed signatures in 9.1. > The current solution to this involves having stub functions in core > with the old signatures; when you do an upgrade from the 9.0 version > of one of these contrib modules, its opclass will be pointing at the > stub version instead of the preferred version. I guess we could fix > that with a direct UPDATE on pg_amproc but I'm not sure that's a > good idea. Note these functions aren't actually *members* of the > extensions, just things it references, so the odds of future trouble > seem pretty small. On the other hand, if we don't do this, it's > unclear when we'll ever be able to get rid of the stubs. > > Comments?
ISTM that the pg_amproc entries are part of the operator class, which is owned by the extension. So it's the upgrade script's job to leave the operator class in the right state. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
