Re: BUG #16492: DROP VIEW IF EXISTS error

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Nina Marlow <postgresql(dot)2020(at)t-net(dot)ruhr>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #16492: DROP VIEW IF EXISTS error
Date: 2020-06-14 17:12:15
Message-ID: 1050585.1592154735@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message David G. Johnston 2020-06-14 18:12:05 Re: BUG #16492: DROP VIEW IF EXISTS error
Previous Message David G. Johnston 2020-06-14 16:19:36 Re: BUG #16492: DROP VIEW IF EXISTS error