Martijn van Oosterhout <kleptog@svana.org> writes:
> Hmm. By feature I assume you mean "ORDER BY ... USING" (which no-one
> could find an example of) and not "requiring the operator to be part of
> an opclass".
> In fact, I don't think we ever need to remove the syntax, just as long
> as the operator is part of an operator class, it'll be fine.
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.
I haven't had time yet to digest the material you posted yesterday about
COLLATE. Maybe there's a solution in there, but I think it could only
happen if we assume that every potential sort operator appears in only
one opclass. Which seems like a pretty restrictive assumption, even
granted that COLLATE will start to carry some of the load of picking
different sorting options.
What I'd really like is to deprecate the "USING operator" syntax in
favor of a "USING operatorclassname" syntax. Actually, "USING opclass
[ASC/DESC]" would get the job done, since given an opclass you can
certainly run the sort function either normal or reverse.
We could keep the "USING operator" syntax but insist that it's only
allowed if there's exactly one possible opclass mapping.
regards, tom lane
