Re: Operators and commutation

Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> writes:
> Tom, can you refresh my memory on the preferred way to define
> "commutative operators" for operators with mixed input types? For
> example, I want to define a new operator to add an interval to a time.
> Do I need to fully implement the commutative function which adds a time
> to an interval, or is there another way?

No other way. The commutative-operator stuff doesn't exist to make
life easy for the parser; it exists to make life easy for the executor,
specifically for the indexscan machinery, which thinks that indexscan
qualifiers are always "indexedvar OP constant" and never "constant OP
indexedvar". If you try to flip the order to make life easy in the
parser, the planner will likely just flip it back again.

> I used to have a cheat interpretation of commutation during operator
> matching in the parser (which allowed a mixed-type operator to refer to
> itself as its commutator, and the parser would then flip the arguments
> around to match up), but I recall that you took this out to reinforce
> the purity of the interpretation of commutation in the table flags.

IIRC, I took it out because the oprsanity regress test was spitting up
on it. But that's just the tip of the iceberg. You could put it back
if you want to fix the executor, the planner's knowledge that the
executor wants "var OP constant", and oprsanity.sql. And maybe some
other places :-(

Having said all that, I'm not sure that the planner is really all that
smart about reversing "const OP var" into "var OP const" for an index
scan when the var and const are of different types. And this is all
*totally* irrelevant for operators that are not index-related, ie,
referenced in pg_amop. If you're concerned about a "time + interval =>
time" operator, I suggest just not marking it commutative for now.
There's no value in making a commutator entry for a non-indexable
operator.

regards, tom lane