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

From Pavel Stehule
Subject Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS
Date
Msg-id CAFj8pRBHmxE_tZwc49UCpy9MaVg83htwBQ=PqE8=Y+M8THSgqA@mail.gmail.com
Whole thread Raw
In response to Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers


2018-07-04 23:17 GMT+02:00 Tom Lane <tgl@sss.pgh.pa.us>:
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.

+1 DROP ROUTINE proposal

Regards

Pavel


                        regards, tom lane

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: PANIC during crash recovery of a recently promoted standby
Next
From: Masahiko Sawada
Date:
Subject: Re: Copy function for logical replication slots