On Thu, Feb 17, 2011 at 9:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Robert Haas robertmh...@gmail.com writes:
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 robertmh...@gmail.com writes:
On Thu, Feb 17, 2011 at 9:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
2. intarray and tsearch2 use some core support functions in their
GIN opclasses, and those support functions changed signatures in 9.1.
The current solution to this involves having
On Fri, Feb 18, 2011 at 12:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Feb 17, 2011 at 9:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
2. intarray and tsearch2 use some core support functions in their
GIN opclasses, and those support functions
Robert Haas robertmh...@gmail.com writes:
On Fri, Feb 18, 2011 at 12:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
OK, I held my nose and inserted UPDATE commands to make the opclasses
match. AFAICT the only remaining discrepancy between contrib modules
made fresh in 9.1 and those updated from
Tom Lane t...@sss.pgh.pa.us writes:
OK. Thanks for nailing all of this down - that's got to have been a
heck of a job.
+1
Yeah, it was a bit of a pain, and took longer than I would've hoped.
Well, with some luck (and effort) 9.2 will have the missing DDL pieces.
I think the extension
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
On Thu, Feb 17, 2011 at 12:16 PM, Tom Lane t...@sss.pgh.pa.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
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
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,
I wrote:
Robert Haas robertmh...@gmail.com writes:
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
Robert Haas robertmh...@gmail.com writes:
On Tue, Feb 15, 2011 at 7:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
2. We could add extra pg_proc.h entries matching the old signatures.
For the moment these would be stub functions that call the same C code,
though eventually perhaps they could be
On Wed, Feb 16, 2011 at 11:29 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Hmm. Can we just invent a way to hook them from the opclasses? I
have a feeling that now that this extension stuff is in we're going to
discover a bunch of these little utility commands that we managed to
get by without in
On Wed, Feb 16, 2011 at 12:24 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 16.02.2011 19:17, Robert Haas wrote:
The trouble is that we have no mechanism for conditional logic in
upgrade scripts,...
Can't you put a DO-block there? It's not pretty, but should work..
Robert Haas robertmh...@gmail.com writes:
The trouble is that we have no mechanism for conditional logic in
upgrade scripts, so if the system catalog structure should change in a
way that causes the hook and unhook mechanism to require different
logic depending on which PG major version is in
On 16.02.2011 19:17, Robert Haas wrote:
The trouble is that we have no mechanism for conditional logic in
upgrade scripts,...
Can't you put a DO-block there? It's not pretty, but should work..
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers
On Wed, Feb 16, 2011 at 12:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
The trouble is that we have no mechanism for conditional logic in
upgrade scripts, so if the system catalog structure should change in a
way that causes the hook and unhook mechanism
Robert Haas robertmh...@gmail.com writes:
Well, it sounds like we're in agreement at least about 9.1, so we can
leave the rest of the argument to another day. I *am* surprised that
you think it would take *thousands* of lines of code.
Well, it all depends on how much ALTER stuff you want to
Tom Lane t...@sss.pgh.pa.us writes:
Well, actually, we *do* have such a mechanism (plpgsql), we just don't
want to use it unless we have to. I wouldn't feel too bad about saying
upgrading tsearch2 directly from 9.0 to 9.4 requires that you have
plpgsql installed when you issue the CREATE
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
Well, actually, we *do* have such a mechanism (plpgsql), we just don't
want to use it unless we have to. I wouldn't feel too bad about saying
upgrading tsearch2 directly from 9.0 to 9.4 requires that you have
On Feb 16, 2011, at 1:20 PM, Dimitri Fontaine wrote:
We will then need build-time requires (build-depends would say debian)
so that the system knows what's needed to run the install or upgrade
scripts. I've been thinking that's for 9.2, but maybe that would be a
simpler fix for you here.
On Tue, Feb 15, 2011 at 7:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
1. We could just revert the pg_proc.h changes so that these two
functions are still shown as taking only 2 arguments. Since GIN doesn't
actually look at the signature claimed in pg_proc, this won't break
anything
21 matches
Mail list logo
