"Dimitri Fontaine" <dfontaine@hi-media.com> 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'sPostgreSQL training!
