Tom Lane wrote: > > also, object locks need to be acquired, which > > can be very troublesome if you discover that some frequently-used object > > is in the set to be dropped, by some unfortunate accident. > > You'd need the object locks in any case, to be sure things hold still long > enough for their dependencies to be examined. It's possible a weaker lock > type would suffice, but I'm not sure; we generally don't require exclusive > lock on an object to add or remove dependencies on it.
Of course, using a weak lock could run afoul of somebody changing the dependencies underneath. But even using a stronger lock is unlikely to give any actual protection: in UI programs (be it GUI admin programs or psql), more likely than not many users are going to run a check in one transaction, then run the actual drop in a different transaction. > I'm not necessarily against adding a function to report the dependencies > as a table rather than NOTICE output. But things have been like this > for quite a few years and I can count the number of requests for such a > function without running out of thumbs. Doesn't seem very high priority. Sure. Perhaps this'd be a good item for a novice hacker. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs