Re: contrib loose ends: 9.0 to 9.1 incompatibilities

On Thu, Feb 17, 2011 at 12:16 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> So, after some testing, attached are two different fixed-up versions of
> pg_tgrm's update-from-unpackaged script.  The first one leaves the
> parameter lists of some GIN support functions different from what they
> would be if you installed pg_trgrm fresh in 9.1.  The second one fixes
> the parameter lists too, by means of really ugly direct UPDATEs on
> pg_proc.  I'm unsure which one to apply --- any opinions?
>
> It's worth noting that both versions still leave the pg_trgm opclasses a
> bit different from a fresh install, because the added operators are
> "loose" in the opfamily rather than being bound into the opclass.  This
> hasn't got any real functional effect, but if you were feeling paranoid
> you could worry about whether the two different states could cause
> problems for future versions of the update script.  As far as I can see,
> the only thing we could realistically do about this with the tools at
> hand is to change pg_trgm's install script so that it also creates the
> new-in-9.1 entries "loose".  That seems a tad ugly, but depending on
> where you stand on the paranoia scale you might think it's a good idea.
> There is definitely no point in that refinement unless we update the
> function parameter lists, though.
>
> Comments?

I think we should try to make the state match as closely as possible,
no matter how you got there. Otherwise, I think we're storing up a
host of future pain for ourselves.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company