"David G. Johnston" <david.g.johnston@gmail.com> writes:
> I'm firmly of the belief that the existing behavior of DROP relation IF
> EXISTS is flawed - it should not be an error if there is a namespace
> collision but the relkind of the existing relation doesn't match the
> relkind set by the DROP command.
I don't particularly agree, as I said in the other thread. The core
point here is that it's not clear to me why the specific error of
"wrong relkind" deserves a pass, while other errors such as "you're
not the owner" don't. Both of those cases suggest that you're not
targeting the relation you think you are, and both of them would get
in the way of a subsequent CREATE. To me, success of DROP IF EXISTS
should mean "the coast is clear to do a CREATE". With an exception
like this, a success would mean nothing at all.
Another point here is that we have largely the same issue with respect
to different subclasses of routines (functions/procedures/aggregates)
and types (base types/composite types/domains). If we do change
something then I'd want to see it done consistently across all these
cases.
regards, tom lane
