Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS
Date
Msg-id CAKFQuwZN_btwM7-NcF5R9Fmd0F31we4oPZQGVH8s2Q814SRiyQ@mail.gmail.com
Whole thread Raw
In response to Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
On Tuesday, June 26, 2018, Pavel Stehule <pavel.stehule@gmail.com> wrote:

Just I don't see this proposal as clean win. More it is not limited only this case. It should be consistent with DROP INDEX, SEQUENCE, ... 

Yes, they are likely all broken in the same way and whomever agrees with the "it's bugged" conclusion and is willing and able to write a patch should check them and possibly add those checks as regression tests.

But without a concrete example of problems I'm not going to be convinced there is a downside to fixing this bug.  Given it's converting an error into an equivalent end result without the error I'd support a committer who wants to backpatch whatever fix is devised.

David J.

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS
Next
From: serge@rielau.com
Date:
Subject: RE: Global shared meta cache