Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(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-06-26 17:06:12
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> 2018-06-26 18:22 GMT+02:00 David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)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'

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

regards, tom lane

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2018-06-26 17:15:23 Re: Global shared meta cache
Previous Message serge 2018-06-26 17:03:50 RE: Global shared meta cache