Robert Haas <robertmh...@gmail.com> writes: > On Tue, Feb 15, 2011 at 7:10 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers