Re: contrib loose ends: 9.0 to 9.1 incompatibilities - Mailing list pgsql-hackers

From Tom Lane
Subject Re: contrib loose ends: 9.0 to 9.1 incompatibilities
Date
Msg-id 12515.1297968784@sss.pgh.pa.us
Whole thread Raw
In response to Re: contrib loose ends: 9.0 to 9.1 incompatibilities  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: contrib loose ends: 9.0 to 9.1 incompatibilities  (Robert Haas <robertmhaas@gmail.com>)
Re: contrib loose ends: 9.0 to 9.1 incompatibilities  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Feb 17, 2011 at 12:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.

Well, if you're willing to hold your nose for the "UPDATE pg_proc" hack,
we can make it so.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Marko Tiikkaja
Date:
Subject: Re: remove upsert example from docs
Next
From: Robert Haas
Date:
Subject: Re: COPY ENCODING revisited