Paul Ramsey <pram...@cleverelephant.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