Re: [BUG?] tgconstrrelid doesn't survive a dump/restore
От | Joel Burton |
---|---|
Тема | Re: [BUG?] tgconstrrelid doesn't survive a dump/restore |
Дата | |
Msg-id | Pine.LNX.4.21.0104181622020.24973-100000@olympus.scw.org обсуждение исходный текст |
Ответ на | Re: [BUG?] tgconstrrelid doesn't survive a dump/restore (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Re: [BUG?] tgconstrrelid doesn't survive a
dump/restore
|
Список | 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 по дате отправления: