Re: [BUG?] tgconstrrelid doesn't survive a dump/restore - Mailing list pgsql-hackers

From Joel Burton
Subject Re: [BUG?] tgconstrrelid doesn't survive a dump/restore
Date
Msg-id Pine.LNX.4.21.0104181622020.24973-100000@olympus.scw.org
Whole thread Raw
In response to Re: [BUG?] tgconstrrelid doesn't survive a dump/restore  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: [BUG?] tgconstrrelid doesn't survive a dump/restore  (Philip Warner <pjw@rhyme.com.au>)
List pgsql-hackers
On Wed, 18 Apr 2001, Tom Lane wrote:

> Joel Burton <jburton@scw.org> writes:
> > tgconstrrelid (in pg_trigger) holds table references in a RI trigger.
> > The value in this field is not successfully recreated after a
> > dump/restore.
> 
> Yes, this problem was noted a couple months ago.  AFAIK it was not fixed
> for 7.1, but I concur that it should be fixed.

Jan/Philip/Tom --

Do we know if the problem is in pg_dump, or is there no way
to pass the tgconstrrelid value in the CREATE CONSTRAINT TRIGGER
statement?

(I've read the dev docs on RI, but I haven't seen anyplace that
documents what the arguments for the call are exactly, and a muddled
wading through the source didn't help much.)

If there are no better suggestions for the before-the-real-fix fix, I
could make RI_pre_dump() and RI_post_dump() functions that would stick
this information into another table so that I won't lose that info. (Or,
can I always rely on digging it out of the preserved fields in pg_trig?)

Thanks!

-- 
Joel Burton   <jburton@scw.org>
Director of Information Systems, Support Center of Washington



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Re: No printable 7.1 docs?y
Next
From: ncm@zembu.com (Nathan Myers)
Date:
Subject: Re: CRN article not updated