Re: BUG #16492: DROP VIEW IF EXISTS error

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

> On Friday, June 12, 2020, PG Bug reporting form <noreply(at)postgresql(dot)org>
> wrote:
>
>> The following bug has been logged on the website:
>>
>> Bug reference: 16492
>> Logged by: Nina Marlow
>> Email address: postgresql(dot)2020(at)t-net(dot)ruhr
>> PostgreSQL version: 12.3
>> Operating system: Linux/Docker
>> Description:
>>
>> When trying to use "DROP VIEW IF EXISTS x" while a table named "x" exists,
>> the DROP statement raises an "Error: x is not a view".
>>
>> The documentation says about the "IF EXISTS" clause:
>>
>> > Do not throw an error if the view does not exist. A notice is issued in
>> this case.
>>
>> Imho, there shouldn't be an error if the view does not exist regardless of
>> whether or not a table with this name exists. The observed behavior is
>> contrary to the sense of the "IF EXISTS" clause as one would have to check
>> whether a table with the desired name exists before using "DROP VIEW IF
>> EXISTS". But then you could directly check whether or not the view itself
>> exists.
>>
>
> This thread from 2018 illustrates the current state of the discussion:
>
>
> https://www.postgresql.org/message-id/flat/CAFj8pRD-Lq%3D9ZTHuAdq1RYW4EN0O5Pr0cvCUZs5%3DMUzs2dLCXQ%40mail.gmail.com#9f9dfcca54742947c7140c9789e6b82a
>
> I still concur this is indeed a bug that should be fixed.
>

It is hard to find an agreement here. Both alternatives has benefits and
disadvantages. Just depends on personal view. One direction is more
tolerant behaviour (more user friendly). Second direction is more strict
behaviour (developer friendly).
Probably preferences depends if somebody use DROP as an isolated command or
not. I use DROP IF EXISTS together with CREATE statement, and for me is
natural current design.

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.

Because I use these statements typically in pair, then I prefer current
behaviour. I am not sure what is the best design here, but I don't think so
this case is a bug. It is just ambiguous.

Nice evening

Pavel

> David J.
>
>