Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

On Wednesday, July 4, 2018, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.