On Fri, Feb 18, 2011 at 12:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Thu, Feb 17, 2011 at 9:13 PM, Tom Lane <tgl@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
