> When you drop a table, there are only so many things that could depend on
> it:
>
> * rules/views
> * triggers
> * check constraints
> * foreign key constraints
> * primary key constraints
> * unique constraints
> * subtables
>
> including their dependencies. There might be others I forgot but a
> finite list can be defined.
>
> When a table is dropped, you scan all of these objects (their system
> catalogs) for matches against the table and either do a cascade or
> restrict. This is not new, we already do this for indexes and
> descriptions, for instance.
Here is how I see it. If you use the pg_depend table to track these
dependencies, you know at the time you do the insert where they come
from so why not just record it at that time? Why poke around later
looking at many system tables? The big issue is that you can pretty
much centralize the stuff during INSERT and just use that on
DROP/RENAME. I can even see a loop that says, "I am OK with sequence
dependencies, but not other pg_class dependencies" or stuff like that.
You can just trigger on the sysrelid in the table and determine where to
go. If not you have to have all sorts of system poking code in
DROP/RENAME, unless you want to just call a function to hit _every_
system table looking for the oid, which I doubt you want to do.
-- 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