BUG #16492: DROP VIEW IF EXISTS error

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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: BUG #16492: DROP VIEW IF EXISTS error
Date: 2020-06-14 19:04:07
Message-ID: CAKFQuwYGaaoF8XKWLOxGfjeFeUuH=wmwiDCgZz5e3SP34qJtGw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Sunday, June 14, 2020, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> 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
>

IMO if the DROP type IF EXISTS worked as expected the drop relation command
would be undesirable - the use case being that there is a specific type of
object the user was potentially expecting to exist that they want to ensure
does not. If an object of a different typed gets matched for some reason
it should not get dropped as a safety feature.

Unless drop relation is part of the SQL standard I’d suggest it is
something to not implement on “don’t give users a loaded weapon” grounds.
People aren’t clamoring for it and making the drop type if exists work in
the proposed manner makes it possible to, if a bit verbosely, replicate the
same behavior in the rare case it would be needed. The same rarity that is
being used to defend not changing the behavior.

David J.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message David Rowley 2020-06-14 22:12:34 Re: pgbench bug / limitation
Previous Message David G. Johnston 2020-06-14 18:12:05 Re: BUG #16492: DROP VIEW IF EXISTS error