Re: dealing with extension dependencies that aren't quite 'e'

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Abhijit Menon-Sen <ams(at)2ndQuadrant(dot)com>
Cc: David Steele <david(at)pgmasters(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
Subject: Re: dealing with extension dependencies that aren't quite 'e'
Date: 2016-04-01 15:00:21
Message-ID: 20160401150021.GA16414@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Abhijit Menon-Sen wrote:
> At 2016-03-29 10:15:51 -0400, david(at)pgmasters(dot)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

Álvaro Herrera
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2016-04-01 15:02:49 Re: Logical Decoding - Execute join query
Previous Message Alvaro Herrera 2016-04-01 14:45:18 Re: snapshot too old, configured by time