| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
| Cc: | 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-06-26 17:03:25 |
| Message-ID: | CAKFQuwZN_btwM7-NcF5R9Fmd0F31we4oPZQGVH8s2Q814SRiyQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tuesday, June 26, 2018, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | serge | 2018-06-26 17:03:50 | RE: Global shared meta cache |
| Previous Message | Pavel Stehule | 2018-06-26 16:47:47 | Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS |