Re: BUG #16492: DROP VIEW IF EXISTS error - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #16492: DROP VIEW IF EXISTS error
Date
Msg-id 1050585.1592154735@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #16492: DROP VIEW IF EXISTS error  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: BUG #16492: DROP VIEW IF EXISTS error  ("David G. Johnston" <david.g.johnston@gmail.com>)
BUG #16492: DROP VIEW IF EXISTS error  ("David G. Johnston" <david.g.johnston@gmail.com>)
Re: BUG #16492: DROP VIEW IF EXISTS error  (Nina Marlow <postgresql.2020@t-net.ruhr>)
List pgsql-bugs
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> How is the proposed behavior more risky?  And no, the current behavior does
> not have any uniquely practical use.  Its only benefit is that it is how
> things have worked forever and that is only because its flaws are rarely
> encountered in practice.

I'm a little skeptical about the proposed change being of any benefit.
The usual reason for doing DROP IF EXISTS is that you're about to replace
the object.  It will not help for the DROP to succeed if the conflicting
object is still there, because the CREATE is going to fail anyway.  Thus,
the most likely effect of such a change is that we fix no scripts, while
breaking any scripts that were dependent on the existing behavior.

What I'd prefer to see, I think, is a command DROP RELATION [IF EXISTS]
that is entirely un-picky about the object's relkind.  Once upon a time
DROP TABLE worked that way, IIRC, but it was "improved" with little
thought about the needs of schema-update scripts.

            regards, tom lane



pgsql-bugs by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: BUG #16492: DROP VIEW IF EXISTS error
Next
From: "David G. Johnston"
Date:
Subject: Re: BUG #16492: DROP VIEW IF EXISTS error