Skip site navigation (1) Skip section navigation (2)

Re: contrib loose ends: 9.0 to 9.1 incompatibilities

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: contrib loose ends: 9.0 to 9.1 incompatibilities
Date: 2011-02-18 02:13:29
Message-ID: 18496.1297995209@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
I wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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?

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Fujii MasaoDate: 2011-02-18 02:44:08
Subject: Re: [COMMITTERS] pgsql: Hot Standby feedback for avoidance of cleanup conflicts on stand
Previous:From: Alvaro HerreraDate: 2011-02-18 02:12:29
Subject: Re: arrays as pl/perl input arguments [PATCH]

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group