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

> On Feb 26, 2019, at 2:19 PM, Tom Lane <tgl@sss.pgh.pa.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
tohave 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’tbe a constant on either side of the operator. Am I mis-understanding the term, or are there issues with using this
APIin 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