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

> 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
Is there a speed difference with doing a copy on a table with an index
versus creating
the index at the end?  I've been assuming that the latter was faster (and
that that was
part of what he wanted)

> about are constraint expressions that cause references to other tables
> (perhaps indirectly via a function).
Yeah, that's actually a big problem, since that's actually also a constraint
on the other table
as well, and as far as I know, we aren't yet constraining the other table.

> 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.

Does the AddRelationRawConstraints() check that the constraint is satisified
as well when
you add it?   It didn't look like it did, but I could be missing something.
That's another requirement of ALTER TABLE ADD CONSTRAINT.  That was the
bit I wasn't sure how to do for other generic constraints when I added the
foreign key one.