From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | Peter Moser <pitiz29a(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS |
Date: | 2018-06-26 16:47:47 |
Message-ID: | CAFj8pRCZrLo0trK4m-nOornRchy1C72_56L7-5Ue1TFYdUAdSw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2018-06-26 17:03:25 | Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS |
Previous Message | David G. Johnston | 2018-06-26 16:22:12 | Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS |