Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Peter Moser <pitiz29a(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS
Date: 2018-07-04 21:33:05
Message-ID: CAKFQuwam6T+A7acAkSgC1GW1Afxudk3bas8NM7bMBhn+CL50RQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-07-04 21:35:05 Re: Cache invalidation after authentication (on-the-fly role creation)
Previous Message Tom Lane 2018-07-04 21:23:51 Re: shared-memory based stats collector