On Thu, Feb 17, 2011 at 1:53 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
Yes, I think that's better than leaving things in a different state.
It's not my first choice, but it's better than the alternative.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company