On Tue, 17 Jul 2001, Peter Eisentraut wrote:
> Tom Lane writes:
>
> > The alternative to pg_depend is to do a brute force scan of all the
> > system catalogs looking for dependent objects. In that case, you'd
> > know what you are looking at, but if we extract the dependencies as
> > a separate table, I don't see how you'd know without being told.
>
> The former is what I'm advocating.
Why? It's grossly inefficient and requires lots of effort. And scales
horribly to adding new things which can depend on others.
Following that argument (admittedly to an extreme conclusion), we should
rip out index support. After all, all of the info in the index is stored
in the table, we don't need to duplicate it elsewhere.
pg_depend is a concise way to encode dependencies. We do all of the work
at insert, where we know what depends on what. To not have pg_depend means
that on delete, we have to scan EVERYTHING to see what depends on what
we're dropping. If we find something (and are CASCADEing), we have to
check and see if _it_ depends on anything (another complete scan). We have
to keep doing complete scans until we find nothing.
Take care,
Bill
