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
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 |