Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

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.

David J.