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