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.
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 |