Abhijit Menon-Sen wrote: > At 2016-03-29 10:15:51 -0400, da...@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
