Patrick Welche's recent problems (see pgsql-general) point out that the
old CREATE CONSTRAINT TRIGGER syntax that optionally omits a "FROM
table" clause doesn't work anymore --- the system *needs* tgconstrrelid
to be set in an RI constraint trigger record, because the RI triggers
now use that OID
On Thu, 2002-09-26 at 16:57, Tom Lane wrote:
> This means that RI trigger definitions dating back to 7.0 (or whenever
> it was that we fixed the pg_dump bug about not dumping tgconstrrelid)
> don't work anymore.
I thought 7.0 introduced foreign keys in the first place, so perhaps
7.1?
However, i
On Thu, 2002-09-26 at 16:57, Tom Lane wrote:
> There are a couple things I think we should do. One: modify the CREATE
> CONSTRAINT TRIGGER code to try to extract a foreign relation name from
> the tgargs if FROM is missing. Without this, we have no hope of loading
> working FK trigger definitio
Rod Taylor <[EMAIL PROTECTED]> writes:
> However, if they're coming from 7.0 or earlier would it be appropriate
> to have them bounce through 7.2 / 7.1 first?
Won't help. 7.2 will dump 'em out without a FROM clause, just like they
were loaded.
> Is this the only problem that 7.0 people are goin
Robert Treat <[EMAIL PROTECTED]> writes:
> I'm trying to think of the cases where this extraction might fail, but
> maybe more important is what happens if it does fail?
Then you have broken RI triggers ... which is the problem now.
regards, tom lane
---
> > Is this the only problem that 7.0 people are going to experience (server
> > side, SQL changes are abundant)?
>
> You're missing the point. Welche was upgrading *from 7.2*. But his
> trigger definitions had a dump/reload history going back to 7.0.
Oh.. I certainly did.
--
Rod Taylor
On Thu, 2002-09-26 at 17:22, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > I'm trying to think of the cases where this extraction might fail, but
> > maybe more important is what happens if it does fail?
>
> Then you have broken RI triggers ... which is the problem now.
>
Uh..
On Thu, 26 Sep 2002, Tom Lane wrote:
> Patrick Welche's recent problems (see pgsql-general) point out that the
> old CREATE CONSTRAINT TRIGGER syntax that optionally omits a "FROM
> table" clause doesn't work anymore --- the system *needs* tgconstrrelid
> to be set in an RI constraint trigger rec
Robert Treat <[EMAIL PROTECTED]> writes:
> On Thu, 2002-09-26 at 17:22, Tom Lane wrote:
>> Robert Treat <[EMAIL PROTECTED]> writes:
> I'm trying to think of the cases where this extraction might fail, but
> maybe more important is what happens if it does fail?
>>
>> Then you have broken RI trigg
Stephan Szabo <[EMAIL PROTECTED]> writes:
>> However, if we are going to put that kind of knowledge into pg_dump,
>> it would only be a small further step to have it dump these triggers
>> as ALTER TABLE ADD CONSTRAINT commands instead. Which would be a lot
>> better for forward compatibility tha
On Thu, 26 Sep 2002, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> >> However, if we are going to put that kind of knowledge into pg_dump,
> >> it would only be a small further step to have it dump these triggers
> >> as ALTER TABLE ADD CONSTRAINT commands instead. Which would b
From: "Tom Lane" <[EMAIL PROTECTED]>
> However, if we are going to put that kind of knowledge into pg_dump,
> it would only be a small further step to have it dump these triggers
> as ALTER TABLE ADD CONSTRAINT commands instead. Which would be a lot
> better for forward compatibility than dumping
Both are done, and in CVS in /contrib/adddepend.
---
Matthew T. O'Connor wrote:
> From: "Tom Lane" <[EMAIL PROTECTED]>
> > However, if we are going to put that kind of knowledge into pg_dump,
> > it would only be a small fu
13 matches
Mail list logo
