From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: contrib loose ends: 9.0 to 9.1 incompatibilities |
Date: | 2011-02-17 17:16:56 |
Message-ID: | 10270.1297963016@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
pg_trgm--unpackaged--1.0.sql | text/x-patch | 3.7 KB |
pg_trgm--unpackaged--1.0-with-update.sql | text/x-patch | 4.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-02-17 17:19:48 | Re: Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit. |
Previous Message | Bruce Momjian | 2011-02-17 17:13:22 | Re: Debian readline/libedit breakage |