Re: Undocumented behavior od DROP SCHEMA ... CASCADE

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