On Wednesday, July 4, 2018, Tom Lane <
tgl@sss.pgh.pa.us> wrote:
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.
I read and agree that what should be possible, absent DROP RELATION, is for someone to execute both DROP VIEW and DROP TABLE with the same name, in any order, and not have the transaction abort with an error (if a table or view of the same name already exists). Having done that the CREATE VIEW will succeed since either both were no-ops (no table or view of that name existed) or one was guaranteed to succeed and the other was a no-op (table or view existed - doesn't matter which). As it stands now you have to know whether the existing object is a table or a view in order to get the order correct and the first run usually the table exists and the second run the view exists so the script has to be changed in between.
If this didn't involve an error mode the desire to leave things as-is would be more understandable to me.
David J.
