Peter Eisentraut <peter_e@gmx.net> writes:
> 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.
Seems like a bad idea; it'll slow down deletes quite a lot, no? Do you
really want to (for example) parse every SQL function in the system to
see if it refers to a table being dropped? Why would we want to do that
work over again for every such delete, rather than doing it once when
an object is created and storing the info in a table? Also consider
that what you are proposing is (at least) an O(N^2) algorithm when there
are a large number of objects.
Furthermore, a separate dependency table would allow us to support
user-defined dependencies. It could be that the user knows function A
should go away if table B does, yet there is no physical dependency that
the system would recognize for it.
regards, tom lane
