Le jeudi 26 juin 2008, Tom Lane a écrit :
> Yeah. The GROUP BY case is even more annoying, because we *have* the
> planner/executor infrastructure to do it via hashing; but the parser
> barfs immediately if there is not btree opclass support for the type.
> I'm not sure how to fix the parser and the parsetree representation
> to be agnostic about hash versus sort implementations --- any thoughts?
Would it be possible to add some semantics to the operator itself?
I'm thinking about indicating that an operator is the equality one without
resorting to OPCLASS and while at it adding the notion of transitivity to
operators (which you'd like to abuse for some joins conditions iirc).
The CREATE OPERATOR =(type, type) (... EQUALITY ...) would give the
information to PostgreSQL and its planner. I'm not sure it current operator
catalog allows us to have a unique constraint for an equality operator for a
given couple of (LEFTARG, RIGHARG), though.
Would this help?
--
dim