Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS
От | Tom Lane |
---|---|
Тема | Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS |
Дата | |
Msg-id | 22733.1530032772@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS
Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS |
Список | 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. 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
В списке pgsql-hackers по дате отправления: