Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> 2018-06-26 18:22 GMT+02:00 David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>:
>>> So I am not sure, if proposed change is practical because views and
>>> tables shares same namespace and current behave has sense too.

>> I'm doubtful that there is any meaningful technical/practical challenge
>> involved here.

Certainly we *could* change it, but it's not at all clear that it's a good
idea. The current behavior seemed sensible when it was implemented, and
it has stood for quite some years now. Now, we have one person
complaining that it wasn't what he expected. If we change the behavior on
the strength of that, will we change it back on the first complaint from
someone else? What about the possibility that the change breaks peoples'
applications?

I think there might be grounds for clarifying the documentation, but
I'm quite hesitant to change the behavior without someone making a case
a whole lot stronger than this.

Also worth noting is that similar issues arise elsewhere, eg we now
have "procedures" vs "functions" in a single namespace. Let's not have
DROP TABLE acting in a way that's inconsistent with other parts of the
system.

regards, tom lane