Re: BUG #16492: DROP VIEW IF EXISTS error

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: "postgresql(dot)2020(at)t-net(dot)ruhr" <postgresql(dot)2020(at)t-net(dot)ruhr>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #16492: DROP VIEW IF EXISTS error
Date: 2020-06-12 20:34:40
Message-ID: CAKFQuwYd+QNZ=CzwvLssJyG-6QVZOjHcWW2Sb+cdVgK6D4-X5A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Friday, June 12, 2020, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>
> DROP TABLE IF EXISTS xxx;
> CREATE TABLE xxx;
>
> If the first statement doesn't fail, then the second statement will be
> successful with very high priority. For me is little bit more intuitive
> message "cannot to drop some" then "cannot to create some" when first
> command is DROP, and I have to investigate, why DROP was ignored.
>

Fixing this bug you’d still get: Error: cannot create table xxx, view with
same name already exists. Do you seriously expect a user to then ask why
the drop table command didn’t tell them about the view with the same name?

The create command should deal with namespace sharing, the drop command
just should do what is written on the tin. Especially since that is all it
is documented to be concerned with. As demonstrated actual use cases are
broken with the current behavior which exists seemingly to only try and
reduce user confusion. I’d rather have the defined and expected behavior
here and deal with confused people on the mailing list then tell people on
their valid uses are not as important.

David J.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2020-06-12 20:38:57 BUG #16493: posgresql has no entry in Volume Shadow Copy Service
Previous Message Pavel Stehule 2020-06-12 20:19:29 Re: BUG #16492: DROP VIEW IF EXISTS error