Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS
| От | David G. Johnston |
|---|---|
| Тема | Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS |
| Дата | |
| Msg-id | CAKFQuwYxnghAwwEDEuodU=wJXQut-MPmMiHUmtKpEBDwxd2aLA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
Pavel Stehule <pavel.stehule@gmail.com> writes:
> 2018-06-26 18:22 GMT+02:00 David G. Johnston <david.g.johnston@gmail.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.
В списке pgsql-hackers по дате отправления: