Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gtHXY-0005p2-GZ for pgsql-hackers@arkaria.postgresql.org; Mon, 11 Feb 2019 19:46:52 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gtHXX-00019r-44 for pgsql-hackers@arkaria.postgresql.org; Mon, 11 Feb 2019 19:46:51 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gtHXW-00019k-Pk for pgsql-hackers@lists.postgresql.org; Mon, 11 Feb 2019 19:46:50 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gtHXU-0002eF-5r for pgsql-hackers@postgresql.org; Mon, 11 Feb 2019 19:46:49 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x1BJkhu2010443; Mon, 11 Feb 2019 14:46:43 -0500 From: Tom Lane To: Alvaro Herrera cc: Peter Geoghegan , PostgreSQL Hackers Subject: Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages) In-reply-to: <20190211015423.GA16289@alvherre.pgsql> References: <20190211015423.GA16289@alvherre.pgsql> Comments: In-reply-to Alvaro Herrera message dated "Sun, 10 Feb 2019 22:54:23 -0300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10441.1549914403.1@sss.pgh.pa.us> Date: Mon, 11 Feb 2019 14:46:43 -0500 Message-ID: <10442.1549914403@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk I've pushed this now. I made one additional change, which was to fix things so that if both an INTERNAL and an EXTENSION dependency exist, the first loop will reliably complain about the EXTENSION dependency. It only takes one more if-test to do that now that we're postponing the error report till after the loop, and this way we don't need to split hairs about how likely it is for both to exist. I think we're done with this thread, though I still need to look at the problem I complained of in <26527.1549572789@sss.pgh.pa.us>. regards, tom lane