Hi, On 2019-01-21 18:52:05 -0500, Tom Lane wrote: > Andres Freund <and...@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
