Memo on dropping practices

Now that the pg_depend mechanism is mostly in there, it is no longer
a good idea to delete things directly (for example, by calling
heap_drop_with_catalog or even just heap_delete'ing a catalog tuple).

The correct thing to do is to call performDeletion() with a parameter
specifying what it is you want to delete.  Object deletion
commands should be implemented in two routines: an outer wrapper that
looks up the object, verifies permissions, and calls performDeletion,
and an inner routine that actually deletes the catalog entry (plus
any other directly-associated work).  The inner routine is called from
performDeletion() after handling any dependency processing that might
be needed.  A good example to look at is the way RemoveFunction()
has been split into RemoveFunction() and RemoveFunctionById().

The payoff for this seeming extra complexity is that we can get rid of
a lot of former hard-wired code in favor of letting dependencies do it.
For instance, heap_drop_with_catalog no longer does anything directly
about deleting indexes, constraints, or type tuples --- that's all
gotten rid of by dependency links when you do a DROP TABLE.  Thus
heap.c is about 300 lines shorter than it used to be.  We also have
much more control over whether to allow deletions of dependent objects.
For instance, you now get fairly sane behavior when you try to drop
the pg_type entry associated with a relation:

regression=# create table foo(f1 int);
CREATE TABLE
regression=# drop type foo;
ERROR:  Cannot drop type foo because table foo requires it       You may DROP the other object instead


I notice that Tatsuo recently committed DROP CONVERSION code that does
things the old way.  I didn't try to change it, but as-is it will not
work to have any dependencies leading to or from conversions.  I
recommend changing it so that it can participate in dependencies.
        regards, tom lane