On Thu, Dec 29, 2005 at 10:49:23AM -0500, Tom Lane wrote:
> Well, no, that's not the problem: the problem is that you should be able
> to specify ORDER BY any sort ordering that the system can deal with, and
> the USING syntax is in fact too impoverished to do that. What if the
> mentioned operator is in more than one operator class? I believe that
> ATM the code makes a random choice of which opclass' sort function to
> use, which pretty much sucks.
Ah, that problem. Yeah, at this stage we can't really do much about
that. All I've done at this stage is made it so that if the operator
isn't a member of any operator class it displays:
ERROR: Couldn't find order function associated with operator XXX
HINT: Create a B-tree operator class with this operator in it
Eventually the COLLATE option should make the choice unambiguous. But
I'm not there yet.
One benefit right now is that it permits some code reorganisation to
remove the myFunctionCall2 hack, by passing FunctionCallInfo rather
than FmgrInfo.
> We could keep the "USING operator" syntax but insist that it's only
> allowed if there's exactly one possible opclass mapping.
Can't do that yet, that breaks reverse operator classes. Ofcourse, we
may be able to do it eventually if there's another way to do the same
thing. The main problem being that ORDER BY x ASC is actually made
equivalent to ORDER BY x USING <, so the code still has to work for the
USING case to not break the normal case.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.