Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> One way in which we will lose some flexibility is that this design nails
>> down forevermore the assumption that the indexed column is on the lefthand
>> side of any indexable clause.
> I don't see this as a problem, but if it becomes one we can relabel "left
> operand" as "indexed operand" and "right operand" as "variable operand",
> and add a boolean flag telling which is right and left.
Okay. I won't put in the bool flag for the moment, but I'll use column
names along the lines of "indtype" and "othertype" so that we won't need
to rename the columns if we want to do that in the future.
BTW, I am not planning to remove the possibility of having unary
operators in an opclass. (We have talked about supporting indexing
of IS NULL/IS NOT NULL queries by treating IS(NOT)NULL as a unary
operator --- while I'm not planning to tackle that now, I don't want
to foreclose the possibility.) I think I will specify that "othertype"
for a unary operator should be set equal to the opclass's "indtype",
rather than the more-obvious zero. This will allow the unary operator
to be part of the cached set of operators (which are only going to be
the ones with othertype=indtype).
regards, tom lane
