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

From Tom Lane
Subject Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS
Date
Msg-id 22733.1530032772@sss.pgh.pa.us
Whole thread Raw
In response to Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS
Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS
Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS
List pgsql-hackers
Pavel Stehule <pavel.stehule@gmail.com> writes:
> 2018-06-26 18:22 GMT+02:00 David G. Johnston <david.g.johnston@gmail.com>:
>>> So I am not sure, if proposed change is practical because views and
>>> tables shares same namespace and current behave has sense too.

>> I'm doubtful that there is any meaningful technical/practical challenge
>> involved here.

Certainly we *could* change it, but it's not at all clear that it's a good
idea.  The current behavior seemed sensible when it was implemented, and
it has stood for quite some years now.  Now, we have one person
complaining that it wasn't what he expected.  If we change the behavior on
the strength of that, will we change it back on the first complaint from
someone else?  What about the possibility that the change breaks peoples'
applications?

I think there might be grounds for clarifying the documentation, but
I'm quite hesitant to change the behavior without someone making a case
a whole lot stronger than this.

Also worth noting is that similar issues arise elsewhere, eg we now
have "procedures" vs "functions" in a single namespace.  Let's not have
DROP TABLE acting in a way that's inconsistent with other parts of the
system.

            regards, tom lane


pgsql-hackers by date:

Previous
From: serge@rielau.com
Date:
Subject: RE: Global shared meta cache
Next
From: Andres Freund
Date:
Subject: Re: Global shared meta cache