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