Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

On Tue, Jun 26, 2018 at 10:06 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> 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.

​There are numerous examples of bugs that go unreported until well after a
release is out of support; I'm leaning toward figuring this falls into that
category. A code comment, commit, or email where this was discussed
explicitly would help shift my view here.

> 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?

​I'm not saying change it because someone was confused but because the
wording of the feature leads me to believe that the current implementation
is wrong and...

What about the possibility that the change breaks peoples'
> applications?
>

...it is broken in such a way that I cannot foresee someone relying upon
the existing behavior intentionally.

I'm willing to admit that this is an edge case and fixing it only in 12 is
acceptable. I'm unable to prove a negative here but likewise no one has
shown the negative to be false either.

> 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.
>

​OK.​

> 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.
>

Maybe....VIEWS and TABLES are in many ways interchangeable whereas other
objects sharing a namespace have distinct uses that are different from each
other. For those the choice here doesn't even matter (though if this is how
procedures/functions work I wouldn't be surprise if we got this kind of
complaint for those sooner rather than later) as no one would be running
code where they want to drop a table and create a view of the same name (or
vice-versa I suppose). I'm sure it doesn't happen that often, hence the
lack of reports, but it also a transformation that I wouldn't consider
unreasonable (client code doesn't want to change the logically named
relation even though the DBA wants to change the physical implementation).

David J.