Re: Re: [BUG?] tgconstrrelid doesn't survive a dump/restore
От | Tom Lane |
---|---|
Тема | Re: Re: [BUG?] tgconstrrelid doesn't survive a dump/restore |
Дата | |
Msg-id | 20650.987691228@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Re: [BUG?] tgconstrrelid doesn't survive a dump/restore (Jan Wieck <JanWieck@Yahoo.com>) |
Ответы |
Re: Re: [BUG?] tgconstrrelid doesn't survive a dump/restore
Re: Re: [BUG?] tgconstrrelid doesn't survive a dump/restore |
Список | 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 по дате отправления: