Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1am0Ys-0004fn-Gf for pgsql-hackers@arkaria.postgresql.org; Fri, 01 Apr 2016 15:00:34 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1am0Yq-0003S3-Ra for pgsql-hackers@arkaria.postgresql.org; Fri, 01 Apr 2016 15:00:32 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1am0Yp-0003RO-SF for pgsql-hackers@postgresql.org; Fri, 01 Apr 2016 15:00:31 +0000 Received: from smtp-auth.no-ip.com ([8.23.224.61] helo=out.smtp-auth.no-ip.com) by magus.postgresql.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1am0Yj-0005Cn-VH for pgsql-hackers@postgresql.org; Fri, 01 Apr 2016 15:00:30 +0000 X-No-IP: alvh.no-ip.org@noip-smtp X-Report-Spam-To: abuse@no-ip.com Received: from alvin.alvh.no-ip.org (unknown [200.83.202.40]) (Authenticated sender: alvh.no-ip.org@noip-smtp) by smtp-auth.no-ip.com (Postfix) with ESMTPA id 0E2EB40079B; Fri, 1 Apr 2016 08:00:23 -0700 (PDT) Received: by alvin.alvh.no-ip.org (Postfix, from userid 1000) id 0C5606C4; Fri, 1 Apr 2016 12:00:21 -0300 (CLT) Date: Fri, 1 Apr 2016 12:00:21 -0300 From: Alvaro Herrera To: Abhijit Menon-Sen Cc: David Steele , Robert Haas , pgsql-hackers@postgresql.org, Alexander Korotkov Subject: Re: dealing with extension dependencies that aren't quite 'e' Message-ID: <20160401150021.GA16414@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160401123136.GA6379@toroid.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Pg-Spam-Score: -1.1 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Abhijit Menon-Sen wrote: > At 2016-03-29 10:15:51 -0400, david@pgmasters.net wrote: > > > > Either way it looks like you need to post a patch with more > > documentation - do you know when you'll have that ready? > > Here it is. > > (I was actually looking for other potential callers, but I couldn't find > any. There are some places that take a RangeVar and make a list from it, > but they are creating new nodes, and don't quite fit. So the only change > in this patch is to add a comment above the get_object_address_rv > function.) > > Álvaro, do you like this one any better? Well, yes and no. It's certainly much cleaner than the other approach IMO. But this patch makes me consider the following question: could I use this to implement ExecRenameStmt, instead of the current code? It's not a trivial question, because the current rename code goes through RangeVarGetRelidExtended with custom callbacks, to ensure that they have the correct object before locking. get_object_address also has some protections against this, but I'm not really clear on whether they offer the same guarantees. If they do, we could replace the rangevar lookup with the new get_object_address_rv and the end result would probably turn out simpler. At this point I hate myself for introducing the SQL-accessible code for get_object_address and friends; we could change the representation of what comes out of the parser, but that functionality would be broken if we do it now. I think it's okay to change it at some point in the future, given sufficient reason, but I'm not sure that this patch is that. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers