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

Paul Ramsey <pramsey(at)cleverelephant(dot)ca> writes:
> On Jan 19, 2019, at 5:53 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> [ maybe what we need is special index operators for extensions ]

> While I’m not 100% sure what this new thing would “look like” there are at least a few quirky variations on the pattern you’ve correctly identified. So, ST_Intersects(a, b), ST_Contains(a, b) these all match the pattern.

> One that is similar but not quite matching is ST_DWithin(a, b, radius), which expands to
> a && expand(b, radius) and b && expand(a, radius) and _ST_DWithin(a, b, radius)
> so the operator call is doubled up and includes a function all on one operand rather than a bare call.

Hm. That seems like it could be made to fit the pattern. The basic
charter of the transform function I have in mind would be "given this
function call, produce an indexable clause to apply to this index".
Your example suggests that we might sometimes want to produce more than
one indexable clause, which is an interesting point but not hard to
accommodate --- just have the function return a list rather than
necessarily a single clause. The business with expand() seems like
something the transform function could easily deal with.

I'll try to sketch up a more concrete plan soon.

regards, tom lane