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

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

> Jan Wieck <JanWieck@yahoo.com> writes:
> >     IMHO  there's nothing fundamentally wrong with having pg_dump
> >     dumping the constraints as special triggers, because they are
> >     implemented  in  PostgreSQL  as  triggers. ...
> >     The advantage of having pg_dump output these  constraints  as
> >     proper  ALTER  TABLE  commands  would only be readability and
> >     easier portability (from PG to another RDBMS).
> 
> More to the point, it would allow easier porting to future Postgres
> releases that might implement constraints differently.  So I agree with
> Philip that it's important to have these constructs dumped symbolically
> wherever possible.
> 
> However, if that's not likely to happen right away, I think a quick hack
> to restore tgconstrrelid in the context of the existing approach would
> be a good idea.

A while ago, I wrote up a small tutorial example about using RI
w/Postgres. There wasn't much response to a RFC, but it might be helpful
for people trying to learn what's in pg_trigger. It includes a discussion
about how to disable RI, change an action, etc.

It's at 
http://www.ca.postgresql.org/mhonarc/pgsql-docs/archive/pgsql-docs.200012


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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Some notes on whole-tuple function parameters
Next
From: Joel Burton
Date:
Subject: Re: Re: [BUG?] tgconstrrelid doesn't survive a dump/restore