Re: Changing SQL Inlining Behaviour (or...?)

Paul Ramsey <pramsey(at)cleverelephant(dot)ca> writes:
> Hokay… I’ve read through the patch set, applied it and built it, all works. Am starting to try a test implementation in PostGIS land. Robert’s comment about “PostgreSQL magic” is ringing through my head ... Nodes and Ops and Exprs, oh my! What ever doesn’t kill me only makes me stronger, right? :)

Thanks for looking at it! I think you are going to have some issues
with identifying the operators to use in PostGIS, since unlike the
core code you can't assume fixed OIDs for anything. The other thread
I'd started has some ideas about fixing that, and I hope to get
something into v12 for it, but it's not done yet.

For testing purposes it might be enough to look up your index opfamilies
by name, though I'd not really recommend that as a production answer.

You're also kind of jumping the gun on the documentation ;-). I need
to write a lot more in supportnodes.h about how to use the IndexCondition
callback, but the basic idea is to generate a list of OpExprs (at least
that'd be the normal case) that represent a directly-indexable condition.
It's entirely up to you to ensure that they *are* indexable conditions,
ie with an operator that belongs to the index's opfamily, index key on
the left, pseudoconstant value on the right. The sample code that's
there now for LIKE/regex kind of punts on the last point: since it
can only do anything useful with a simple Const pattern, it doesn't
have to think hard about what's acceptable. If you want to allow
non-simple-Const RHS then you need to reject volatile functions and
Vars of the indexed relation. I was thinking of exposing a function
specifically to make that test, rather than requiring extensions to
copy the logic, but I didn't do it yet.

Anyway, happy to help if you have questions, just ask.

regards, tom lane