Re: DROP TABLE vs inheritance

I wrote:
> it seems that there is a reasonably simple solution: we could make
> find_inheritance_children() and find_all_inheritors() acquire lock
> on each child table as they scan pg_inherits, and do try_relation_open()
> or equivalent to see if the child still exists.  If not, assume the
> table just got dropped and ignore the pg_inherits entry.

I've committed changes along this line, but there was one place that
I thought needed further discussion to decide whether to change it.
That is LockTableCommand(), which has historically attempted to
determine whether the user has privilege on a table before it locks it.
It's still working that way, which means it's at risk of the same
type of child-disappeared problem that I just fixed elsewhere.

I know we've gone back and forth on the question of how LOCK TABLE
should behave, but at the moment I'm leaning towards changing it.
The argument for the way it behaves now seems to be that a user
who has no privileges on a table could cause a momentary denial
of service to those who do by executing LOCK TABLE with an exclusive
lock level.  However, he can do that anyway via ALTER TABLE, which
will happily take out AccessExclusiveLock before it checks any
permissions.  So I'm not seeing the point of risking unsafe behavior
in LOCK TABLE.

Comments?
        regards, tom lane