Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Feb 15, 2011 at 7:10 PM, Tom Lane <tgl@sss.pgh.pa.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
