Re: AW: Proposal: More flexible backup/restore via pg_dump
От | Tom Lane |
---|---|
Тема | Re: AW: Proposal: More flexible backup/restore via pg_dump |
Дата | |
Msg-id | 1315.962306660@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: AW: Proposal: More flexible backup/restore via pg_dump ("Stephan Szabo" <sszabo@kick.com>) |
Список | pgsql-hackers |
"Stephan Szabo" <sszabo@kick.com> writes: >> I had not seen those statements before; I have been mistakenly modifying >> 6.5.3 sources, not 7.0.2. I will incorporate them in my work. Is there any >> way of also disabling all constraint checking while loading the data? > Well, for unique you could remove/recreate the unique index. NOT NULL > is probably not worth bothering with. Check constraints might be able > to be turned off for a table by setting relchecks to 0 in the pg_class > row and the resetting it after data is loaded (sort of like what we do > on data only dumps for triggers). There's no need to disable NOT NULL, nor unique constraints either, since those are purely local to a table --- if they're going to fail, altering load order doesn't prevent it. The things you need to worry about are constraint expressions that cause references to other tables (perhaps indirectly via a function). If we had ALTER TABLE ADD CONSTRAINT then the problem would be largely solved, I believe. This should be a minor exercise --- the heavy lifting is already done, because heap.c's AddRelationRawConstraints() is already set up to be invokable on a pre-existing relation. Also the parser knows how to parse ALTER TABLE ADD CONSTRAINT ... I think all that's missing is a few lines of glue code in command.c. regards, tom lane
В списке pgsql-hackers по дате отправления: