On Mon, Aug 25, 2008 at 10:43:30AM -0400, Tom Lane wrote:
> Martijn van Oosterhout <kleptog@svana.org> writes:
> > 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
>
> Huh? I don't understand why you think we need to expose this to users.
> A user would presumably just write the name of the operator he wants,
> if he's writing out a direct operator call.
The user would, yes. I was talking about the internal representation.
We're talking about the operator name that the parser is going to use
when expanding the BETWEEN clause. Instead of using the string "<=" you
use the string "btree.2" and then in the operator resolution code you
treat that as an operator class lookup. The above construct doesn't
actually work for the end-user because of a parser error.
> To me the issue is what we consider IN and BETWEEN and similar
> constructs to "mean", which in a datatype world boils down to choosing
> which of the datatype's operators to implement the construct with.
I was thinking the problem was using real operator names. Here we make
up an unambiguous name that is not currently in use that can be
resolved to the required operator on demand.
If you define the lookup to always match the type of the left-hand
value you can force consistant semantics. Whether its the semantics you
want is another question.
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.
