Re: Allowing extensions to find out the OIDs of their member objects - Mailing list pgsql-hackers

Hi,

On 2019-01-21 18:52:05 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2019-01-20 18:50:33 -0500, Tom Lane wrote:
> >> In [1] I propose that we should allow extensions to get their hands
> >> on the ability to transform function calls as per "protransform" and
> >> to generate lossy index quals based on items in WHERE clauses.  The
> >> APIs to give an extension control at the right points seem pretty
> >> straightforward, but there's a problem standing in the way of actually
> >> doing anything useful once you've got control.  In order to either
> >> analyze a passed-in clause or generate a new one, the extension will
> >> need to know the OIDs of the functions/operators it's working with.
> >> And extension objects don't have fixed OIDs.
> 
> > Why does it need to know all its oids, rather than just the one of the
> > operation protransform is called for? Am I missing something?  And if
> > so, why isn't it sufficient to just pass in that oid along with the
> > node?
> 
> You would know that the FuncExpr you're given is for the function the
> support function is attached to, sure, and you could pull its OID out
> of that if you wanted.  The problem is that what you want to generate
> frequently involves *other* functions or operators.
> 
> The example Paul gave in the other thread is that given
> 
>     ST_DWithin(a, b, radius)
> 
> we might wish to generate an indexqual like
> 
>     a && expand(b, radius)
> 
> Here, the only OID in easy reach is that of ST_DWithin().  The
> problem is to find out the OIDs of && and expand() so we can build
> new FuncExpr and OpExpr nodes.

I guess I was imagining we'd not create FuncExprs etc, but now that you
say it, that'd be absurdely invasive.  Thanks.


> > Which range are you thinking of handing out here? We use oid ranges as
> > proxy for system-object-ness in a number of places, so we can't really
> > just hand out ones below FirstNormalObjectId. And we can't really hand
> > out any above that, because there'd be conflicts - even if we increased
> > FirstNormalObjectId today, there'd be issues with pg_upgrade.
> 
> Yes, I said in so many words that I was proposing increasing
> FirstNormalObjectId.  I do not think the issues with pg_upgrade itself
> are insoluble --- it would need some historical knowledge about what
> FirstNormalObjectId had been in each prior version, but that's a pretty
> minor problem in the big scheme of things.

Just about every installation uses the oids directly after
FirstNormalObjectId, so that seems fairly painful. It'd be more
realistic to create a new zone at UINT32_MAX - something, but that'd
likely still conflict in plenty installations (thanks to toast and WITH
OIDS tables).   I'm curious as to how to solve that, if you have a
sketch - less because of this, and more because I think it's not
unlikely that we'll encounter the need for this at some point not too
far away.


> I'm probably going to push forward with the OID mapping idea instead.
> That'll be a bit more painful to use, but I don't see any showstopper
> problems ATM.

Cool.

Greetings,

Andres Freund