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-16 16:29:18
Message-ID: 26411.1297873758@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Feb 15, 2011 at 7:10 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 2. We could add extra pg_proc.h entries matching the old signatures.
>> For the moment these would be stub functions that call the same C code,
>> though eventually perhaps they could be changed to throw errors.

> +1.

OK, that's about what I thought too.

>> A related issue is that we similarly changed the signatures of GIN
>> support functions that properly belong to intarray and tsearch2.
>> That affects what the "unpackaged" conversion scripts need to expect.
>>
>> What I'm inclined to do there is just change the scripts to absorb
>> the old functions as-is without trying to correct their signatures.
>> Doing otherwise is a bit painful because they are operator class
>> members, and there's no easy way to unhook them from the opclasses
>> without dropping the opclasses. The only other fix I can think of
>> is a direct UPDATE on pg_proc to fix the proargtypes entries, which
>> would work but seems even uglier.

> Hmm. Can we just invent a way to hook them from the opclasses? I
> have a feeling that now that this extension stuff is in we're going to
> discover a bunch of these little utility commands that we managed to
> get by without in the past but now that we're getting more organized
> about it, we'll need 'em.

Maybe so. My thought is that extension update scripts are going to be
executed in very well-defined circumstances and it might not be so bad
to let them do direct UPDATEs on the system catalogs instead of writing
lots of special-purpose ALTER commands. In the particular case here,
unhooking, deleting, recreating, and rehooking the functions seems like
way more trouble than it's worth.

>> But there's no other answer except embarking on a project to materially
>> upgrade the capabilities of ALTER OPERATOR CLASS/FAMILY, something I
>> really don't want to be doing right now.

> Or maybe that answers my question.

Yeah. Even granted that we should do it someday, today is not that day.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2011-02-16 16:32:21 Re: Sync Rep for 2011CF1
Previous Message Simon Riggs 2011-02-16 16:20:59 Re: CommitFest 2011-01 as of 2011-02-04