Re: Re: [BUG?] tgconstrrelid doesn't survive a dump/restore
От | Jan Wieck |
---|---|
Тема | Re: Re: [BUG?] tgconstrrelid doesn't survive a dump/restore |
Дата | |
Msg-id | 200104191342.IAA01558@jupiter.jw.home обсуждение исходный текст |
Ответ на | Re: Re: [BUG?] tgconstrrelid doesn't survive a dump/restore (Philip Warner <pjw@rhyme.com.au>) |
Ответы |
Re: Re: [BUG?] tgconstrrelid doesn't survive a
dump/restore
Re: Re: [BUG?] tgconstrrelid doesn't survive a dump/restore |
Список | pgsql-hackers |
Philip Warner wrote: > At 16:25 18/04/01 -0400, Joel Burton wrote: > > > >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? > > > > 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 theyare implemented in PostgreSQL as triggers. And the required feature to correctly restore the tgconstrrelidis already in the backend, so pg_dump should make use of it (right now, after a dump/restore, a DROP of a table involved in referential integrity wouldn't correctly remove the triggers from the referencing/referencedopposite table(s)). The advantage of having pg_dump output these constraints as proper ALTER TABLE commands would only be readabilityand easier portability (from PG to another RDBMS). Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com # _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
В списке pgsql-hackers по дате отправления: