Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

Robert Haas <robertmhaas(at)gmail(dot)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