Re: Allowing extensions to supply operator-/function-specific info

> On Feb 26, 2019, at 2:19 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> In most cases, multiple matching arguments are going to lead to
> failure to construct any useful index condition, because your
> comparison value has to be a pseudoconstant (ie, not a variable
> from the same table, so in both of the above examples there's
> no function argument you could compare to).

This term “pseudoconstant” has been causing me some worry as it crops up in your explanations a fair amount. I expect to have queries of the form

SELECT a.*, b.*
FROM a
JOIN b
ON ST_Intersects(a.geom, b.geom)

And I expect to be able to rewrite that in terms of having an additional call to the index operator (&&) and there won’t be a constant on either side of the operator. Am I mis-understanding the term, or are there issues with using this API in a join context?

P.

> But we don't prejudge
> that, because it's possible that a function with 3 or more arguments
> could produce something useful anyway. For instance, if what we've
> got is "f(x, y, constant)" then it's possible that the semantics of
> the function are such that y can be ignored and we can make something
> indexable like "x && constant". All this is the support function's
> job to know.

> regards, tom lane