Re: contrib loose ends: 9.0 to 9.1 incompatibilities

On Tue, Feb 15, 2011 at 7:10 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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