From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Abhijit Menon-Sen <ams@2ndQuadrant.com>
Cc: David Steele <david@pgmasters.net>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-hackers@postgresql.org, Alexander Korotkov <a.korotkov@postgrespro.ru>
Subject: Re: dealing with extension dependencies that aren't quite 'e'
Date: Fri, 1 Apr 2016 12:00:21 -0300
Message-ID: <20160401150021.GA16414@alvherre.pgsql> (raw)
In-Reply-To: <20160401123136.GA6379@toroid.org>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: alvherre@2ndquadrant.com, ams@2ndQuadrant.com, david@pgmasters.net, robertmhaas@gmail.com, a.korotkov@postgrespro.ru
Subject: Re: dealing with extension dependencies that aren't quite 'e'
In-Reply-To: <20160401150021.GA16414@alvherre.pgsql>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox