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