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 <[EMAIL PROTECTED]> http://svana.org/kleptog/ > Please line up in a tree and maintain the heap invariant while > boarding. Thank you for flying nlogn airlines.
signature.asc
Description: Digital signature