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
  [EMAIL PROTECTED]               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Reply via email to