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 по дате отправления: