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
