On Fri, Feb 18, 2011 at 12:01 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Thu, Feb 17, 2011 at 9:13 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> 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. > > OK, I held my nose and inserted UPDATE commands to make the opclasses > match. AFAICT the only remaining discrepancy between contrib modules > made fresh in 9.1 and those updated from 9.0 is the question of citext's > collation property, which as noted in the other thread is not worth > dealing with until the collation stuff is a bit better thought out.
OK. Thanks for nailing all of this down - that's got to have been a heck of a job. -- 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
