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.
> 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. What I'm not seeing a solution
for is how an extension upgrade script could assign fixed OIDs to existing
objects. Since nobody else seems to either see a way to do that, or
even like the idea of fixed OIDs at all, 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.
regards, tom lane
