Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS
Date
Msg-id 67455.1530739048@sss.pgh.pa.us
Whole thread Raw
In response to Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS  ("David G. Johnston" <david.g.johnston@gmail.com>)
Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> Another possibility that would also seem to meet the OP's needs is to
> make it do this:

> DROP TABLE IF EXISTS X;
> NOTICE:  relation "X" is not a table, skipping

> His complaint was really that it generated an ERROR, IIUC.

While that would perhaps meet the OP's desires, it still seems like
a strange definition of "IF EXISTS" to me.  That's supposed to be an
escape hatch for "object does not exist", not for other error types.

The long and short of it is that I'm not dissatisfied with the way
this works now, and given the lack of previous complaints, not
many other people are either.  So I do not think this is a bug fix;
it's a definition disagreement.  I'm inclined to think that the
principle of "stare decisis" ought to apply here --- once we've let
a particular behavior stand for N release cycles, it should take
more than one or two people objecting to change it, because
backwards compatibility.

Also, based on other messages, it seems like what the OP wants is
to be sure that "CREATE TABLE X" will succeed afterwards, so that
failing to get rid of view X will not do what he needs.
There might be some merit in pursuing the DROP RELATION idea that
was floated earlier.  That seems analogous to DROP ROUTINE, which
is dealing with a related case and apparently is standards-compliant.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Legacy GiST invalid tuples
Next
From: Alvaro Herrera
Date:
Subject: Re: Legacy GiST invalid tuples