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.