Re: Memo on dropping practices

Tom Lane wrote:
> 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

Should it be called performDrop rather than Deletion?

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

Yes, this code now allows lots of cleanups we weren't able to do before.
TODO has:

Dependency Checking
===================

* Add pg_depend table for dependency recording; use sysrelid, oid,
depend_sysrelid, depend_oid, name
* Auto-destroy sequence on DROP of table with SERIAL; perhaps a separate
SERIAL type
* Have SERIAL generate non-colliding sequence names when we have
auto-destruction
* Prevent column dropping if column is used by foreign key
* Propagate column or table renaming to foreign key constraints
* Automatically drop constraints/functions when object is dropped
* Make constraints clearer in dump file
* Make foreign keys easier to identify
* Flush cached query plans when their underlying catalog data changes

Which of these are done with the patch?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026