Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

2018-07-04 23:17 GMT+02:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

> 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.
>

+1 DROP ROUTINE proposal

Regards

Pavel

> regards, tom lane
>