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

From Philip Warner
Subject Re: Re: [BUG?] tgconstrrelid doesn't survive a dump/restore
Date
Msg-id 3.0.5.32.20010420003221.02ffb750@mail.rhyme.com.au
Whole thread Raw
In response to Re: Re: [BUG?] tgconstrrelid doesn't survive a dump/restore  (Jan Wieck <JanWieck@Yahoo.com>)
List pgsql-hackers
At 08:42 19/04/01 -0500, Jan Wieck wrote:
>>
>> It's because pg_dump is not designed to dump these constraints *as*
>> constraints. We just need to make pg_dump clever enough to do that.
>
>    IMHO  there's nothing fundamentally wrong with having pg_dump
>    dumping the constraints as special triggers, because they are
>    implemented  in  PostgreSQL  as  triggers.  

Not sure if it's fundamentally wrong, but ISTM that making pg_dump use the
SQL standards whenever possible will make dump files portable across
versions as well as other RDBMSs. It is also, as you say, more readable.


>    and  the required
>    feature to correctly restore the tgconstrrelid is already  in
>    the  backend,  so  pg_dump  should make use of it 

No problem there - just tell me how...



----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|                                |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/


pgsql-hackers by date:

Previous
From: "Henryk Szal"
Date:
Subject: Re: Re: timeout on lock feature
Next
From: Tom Lane
Date:
Subject: Re: Re: [BUG?] tgconstrrelid doesn't survive a dump/restore