Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

2018-06-26 18:22 GMT+02:00 David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>:

> On Tuesday, June 26, 2018, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>>
>> My note is related to @b. I understand to the motivation, but I am not
>> sure if it is good idea. Tables and views shares one namespace.
>>
>
> But the command say "drop table" and so it must only be concerned with
> that subset of the namespace when searching. The note about the view is
> helpful, but it shouldn't change whether the command succeeded with a
> notice or errors.
>
>
>> Often usage of DROP TABLE IF EXISTS is together with CREATE TABLE
>>
>> Now if some does bad reference in DROP TABLE command, then this command
>> fails (first). If we do proposed change, then DROP TABLE do nothing, and
>> CREATE TABLE fails.
>>
>
> Yes, this is what should be happening. CREATE does have to care about the
> whole namespace since it creating a new identifier.
>
>
>> 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. And as you say when doing paired drop/creates one of them
> is going to fail anyway so it doesn't really matter which one. But if
> someone wants to convert a table to a view imdompotently (the point if INE)
> right now they cannot using the features that are documented to do just
> that.
>

Just I don't see this proposal as clean win. More it is not limited only
this case. It should be consistent with DROP INDEX, SEQUENCE, ...

Regards

Pavel

> David J.
>
>