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 ... Not sure about how to name those new clauses, obviously. It seems to me OPERATOR CLASS/FAMILY are all about how to index a given type, not how to offer semantics to type operators, so adding those clauses is "orthogonal" to the existing operator advanced notions. We could require any given type to provide at least an equality operator, whatever the name, and we could even provide equality operators for different types, or for types in the same categories. So int4 = int8 could use or could avoid using the same operator as int8 = int8, e.g. > 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? Regards, -- dim
signature.asc
Description: This is a digitally signed message part.
