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