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

From Tom Lane
Subject Re: Re: [BUG?] tgconstrrelid doesn't survive a dump/restore
Date
Msg-id 20650.987691228@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: [BUG?] tgconstrrelid doesn't survive a dump/restore  (Jan Wieck <JanWieck@Yahoo.com>)
Responses Re: Re: [BUG?] tgconstrrelid doesn't survive a dump/restore  (Joel Burton <jburton@scw.org>)
Re: Re: [BUG?] tgconstrrelid doesn't survive a dump/restore  (Joel Burton <jburton@scw.org>)
List pgsql-hackers
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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Philip Warner
Date:
Subject: Re: Re: [BUG?] tgconstrrelid doesn't survive a dump/restore
Next
From: Peter Eisentraut
Date:
Subject: Re: Re: No printable 7.1 docs?