Tom,
> 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.
Hmmm ... damn, you're correct. It does seem, philosophically, like that is
the appropriate topic for a constraint. However, I can see how it would be
difficult to implement as one ....
What about table-level check constraints? Seems like one of those should be
able to be used to check a vertical assertion within a table. Or do we need
SQL ASSERTION for this?
--
-Josh Berkus
Aglio Database Solutions
San Francisco
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
