Jan Wieck <janwieck@yahoo.com> writes:
> If namespace dropping allows for creation of objects that
> cannot be dropped afterwards any more, I would call that a
> bug or design flaw, which has to be fixed.
I will not require schema support to wait upon the existence of
dependency checking, if that's what you're suggesting.
This does suggest an interesting hole in our thoughts so far about
dependency checking. If someone is, say, trying to drop type T,
it's not really sufficient to verify that there are no existing
tables or functions referencing type T. What of created but as yet
uncommitted objects? Seems like a full defense would require being
able to obtain a lock on the object to be dropped, while creators
of references must obtain some conflicting lock that they hold until
they commit. Right now we only have locks on tables ... seems like
that's not sufficient.
regards, tom lane
