Tom Lane 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 features means we no
Robert Haas writes:
> On Fri, Feb 18, 2011 at 12:01 PM, Tom Lane 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 9.0 is the question of citext's
>>
On Fri, Feb 18, 2011 at 12:01 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Feb 17, 2011 at 9:13 PM, Tom Lane 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
Robert Haas writes:
> On Thu, Feb 17, 2011 at 9:13 PM, Tom Lane 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 stub functions in core
>> with the o
On Thu, Feb 17, 2011 at 9:13 PM, Tom Lane wrote:
> I wrote:
>> Robert Haas 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
I wrote:
> Robert Haas 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" hack,
> we can
On Thu, Feb 17, 2011 at 1:53 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Feb 17, 2011 at 12:16 PM, Tom Lane 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 opfa
Robert Haas writes:
> On Thu, Feb 17, 2011 at 12:16 PM, Tom Lane 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
>>
On Thu, Feb 17, 2011 at 12:16 PM, Tom Lane 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 installed pg_t
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 list
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
Dimitri Fontaine writes:
> Tom Lane 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 iss
Tom Lane 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 EXTENSION command"
Robert Haas 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 add. An
open-ended
On Wed, Feb 16, 2011 at 12:31 PM, Tom Lane wrote:
> Robert Haas 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 dep
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 maili
Robert Haas 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 use, we're hosed.
On Wed, Feb 16, 2011 at 12:24 PM, Heikki Linnakangas
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..
Tom has repeatedly objected t
On Wed, Feb 16, 2011 at 11:29 AM, Tom Lane 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 the past bu
Robert Haas writes:
> On Tue, Feb 15, 2011 at 7:10 PM, Tom Lane 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 changed to throw errors.
> +1.
OK,
On Tue, Feb 15, 2011 at 7:10 PM, Tom Lane 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 functionally. It's pretty
I've been experimenting with dump/reload of 9.0 contrib-using databases
into 9.1 and then applying CREATE EXTENSION FROM to update the contrib
modules to extension style. There are some cases that fail :-(. Most
of them are caused by the GIN extractQuery API changes. In particular,
a 9.0 dump in
22 matches
Mail list logo
