> Nothing. The tuple isn't really gone, and neither are its index
> entries. Getting rid of them later is VACUUM's problem.
So the piece of code at the bottom of the AddRelationRawConstraints function
that adds the tuple to the indices in heap.c is only necessary because it's
_adding_ a tuple?
> BTW, there already is code that cleans out pg_relcheck: see
> RemoveRelCheck() in src/backend/catalog/heap.c.
I am aware of the RemoveRelCheck() function - however it seems to be
somewhat misnamed as it seems to simply delete all CHECKS on a relation.
Another question:
How should I handle RESTRICT/CASCADE? (For CHECK clauses only at the moment)
SQL99 doesn't seem to be 100% clear on this, but it seems that if the user
specifies:
* Nothing: Just drop the constraint, not worrying about dependencies.
(Perhaps issuing a NOTICE if there are.)
* RESTRICT: Refuse to drop the constraint if it's referred to by another
check constraint (impossible?), or if it's referred to in a function or
trigger (how do I check this?) or if a view is dependent on it (impossible?)
* CASCADE: Like RESTRICT, just drop any objects that depend on the
constraint. (This is not easy, and I think I will for the time being issue
an ERROR saying that CASCADE is not implemented.) This is especially
difficult since I doubt that DROP FUNCTION x CASCADE or DROP VIEW x CASCADE
are implemented...?
Lastly, inheritance? I plan to leave out worrying about inheritance for
starters, especially since it seems that half the constraints when added
don't even propagate themselves properly to child tables...
Remarks?
Chris
