Josh Berkus <[EMAIL PROTECTED]> writes:
>> Isn't this already solved by dumping in dependency order?
> Nope. Problem is, the table depends on the function, and the function
> depends on the table. pg_dump (in 7.4.1, at least) will dump the table
> first, *with the constraint*, and then the function ... causing table
> creation to fail.
Um ... by "already" I meant "in CVS tip", not "in 7.4.*". So I'm not
quite sure whether your issue is still live or not. But I'll guess
anyway:
> And this isn't come cross-table function either; the constraint that they're
> implementing is partial uniqueness, which is appropriate for a constraint.
Is it? Our present handling of CHECK constraints cannot reasonably be
thought to support anything but row-local constraints. If they're using
a function to make an end-run around the check that prohibits subselects
in CHECK constraints, then their problems are much more serious than
whether pg_dump dumps the database in an order that manages to avoid
failure. That kind of constraint just plain does not work, because it
won't get rechecked when the implicitly referenced rows change.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
