On Mon, Aug 25, 2008 at 10:43:30AM -0400, Tom Lane wrote: > Martijn van Oosterhout <[EMAIL PROTECTED]> 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 <[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
