On Sun, Aug 24, 2008 at 09:24:23PM -0400, Tom Lane wrote:
> My own feeling is that we should avoid imputing particular semantics
> to particular operator names, and so these constructs should always be
> defined by reference to operators found in a default opclass for the
> datatype, rather than by specific operator names. However, that way
> will likely take more code and cycles to implement than purely
> name-based definitions; and there is also the argument that it violates
> the in-so-many-words definitions given by the spec.
ISTM the problem is that there's no easy way to refer to "operators
found in a default opclass", so perhaps we could invent a construct:
A OPERATOR(btree,2) B
Which would refer to the second operator in the default btree
operator class. The problem is inferring the type, if A and B are
different types, which operator class do you use? When the BETWEEN
construct is expanded, is there currently any guarentee that the chosen
operators will actually be from the same operator class?
As for the negators, I think the parser should simply wrap the whole
expression in NOT and let the optimiser sort it out.
You could then use it in other places, like LIKE optimisation or the
ORDER BY clause. Essentially anywhere where currently there are
assumptions about the real operator name is required. And then the
optimiser can fill in the actual operator by which time it should be
clear what it is.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.