Re: BUG #16492: DROP VIEW IF EXISTS error

pá 12. 6. 2020 v 22:34 odesílatel David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> napsal:

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

If we change the behaviour then other group of users will be confused in
other cases. For me - this case is ambiguous, and the change doesn't do
things better for all.

I try to think about it from a different perspective and I don't see any
result. Minimally

postgres=# create table xxx (a int);
CREATE TABLE
postgres=# drop view xxx;
ERROR: "xxx" is not a view
HINT: Use DROP TABLE to remove a table.

DROP TABLE IF EXISTS and DROP TABLE are consistent now. The message is
""xxx" is not a view", it is not ""xxx" doesn't exist".

I would like to see the opinions of other people. I don't see "fixing this
case" as a clean win. I see the benefits and disadvantages.

Pavel

> David J.
>