On Tue, Feb 15, 2011 at 7:10 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 1. We could just revert the pg_proc.h changes so that these two > functions are still shown as taking only 2 arguments. Since GIN doesn't > actually look at the signature claimed in pg_proc, this won't break > anything functionally. It's pretty ugly though, and potentially will > confuse people down the road.
-1. > 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. > 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. > There are some similar issues in pg_trgm as well. I believe we can fix > these with the available facilities so long as we don't mind the fact > that opclasses upgraded from 9.0 installations will be subtly different > from ones installed fresh in 9.1, for example the new operators being > considered "loose" in the opfamily instead of being bound into an > operator class. While I don't immediately see any problems likely to > arise from that, it's something that could perhaps bite us eventually. > 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. > BTW, none of these issues are new with the extensions patch; they are > things we broke awhile ago. I'm thinking it's really past time that > we set up some routine buildfarm-style testing to see if pg_upgrade > from the previous version still works. Yeah. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
