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*
HaveSERIAL generate non-colliding sequence names when we have auto-destruction* Prevent column dropping if column is
usedby foreign key* Propagate column or table renaming to foreign key constraints* Automatically drop
constraints/functionswhen 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@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026