"Dimitri Fontaine" <[EMAIL PROTECTED]> writes: > Le lundi 25 août 2008, Martijn van Oosterhout a écrit : >> 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: > > Perhaps here again we're showing a need for some higher level semantics about > operators and types. The case was recently raised about equality operators > and operators transitivity, but I can't find the archive reference just now. > Maybe we should add some common semantics to operators. CREATE OPERATOR would > support some new clauses: > IS_TRANSITIVE > IS_EQUALITY > IS_LT > IS_LE > ...
I'm not sure it's made explicit anywhere in the documentation but those properties *are* what btree operator classes define. You would end up duplicating the same structures (like, LT is meaningless unless you associate it with the corresponding EQUALITY, LE, GT, and GE operators). >> assumptions about the real operator name is required. And then the >> optimiser can fill in the actual operator by which time it should be >> clear what it is. > > How would the planner get the estimated costs associated to any operator > choice in this case? We don't need to evaluate costs until well after this point. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
