On Tue, Feb 15, 2011 at 7:10 PM, Tom Lane <tgl@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