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
signature.asc
Description: This is a digitally signed message part.
