On Thu, Feb 17, 2011 at 1:53 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Thu, Feb 17, 2011 at 12:16 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
