Skip site navigation (1) Skip section navigation (2)

Re: AW: Proposal: More flexible backup/restore via pg_dump

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Stephan Szabo" <sszabo(at)kick(dot)com>
Cc: "Philip Warner" <pjw(at)rhyme(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: AW: Proposal: More flexible backup/restore via pg_dump
Date: 2000-06-29 19:24:20
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
"Stephan Szabo" <sszabo(at)kick(dot)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

In response to


pgsql-hackers by date

Next:From: Stephan SzaboDate: 2000-06-29 19:50:02
Subject: Re: AW: Proposal: More flexible backup/restore via pg_dump
Previous:From: Timothy H. KeittDate: 2000-06-29 19:06:32
Subject: finding lib/include dirs

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group