Re: extended operator classes vs. type interfaces

Robert Haas wrote:
> On Sat, Apr 10, 2010 at 12:05 PM, Yeb Havinga <yebhavinga(at)gmail(dot)com> wrote:
>
>> Jeff Davis wrote:
>>
>>> To give some context, I started a thread a while ago:
>>>
>>> http://archives.postgresql.org/pgsql-hackers/2009-10/msg01403.php
>>>
>>>
>> Interesting, a join type for overlaps, which makes me think a bit of the
>> staircase join for pre-post coordinates. However, does a join operator type
>> need certain kinds of properties of the operator involved, e.g. being
>> commutative, transitive etc? Else the join reordering fails. The latter
>> fails for the overlap operator.
>>
>
> I don't think I follow this. As far as I know, the join order
> constraints don't depend on the choice of operator.
>
I was thinking of a case for instance for ranges a,b,c in relations
A,B,C respectively, where a && b and b && c, but not a && c. Would the
planner consider a join path of table A and C first, then that result
with B. After looking in doxygen, it looks like having && defined
without MERGES is what prevents this unwanted behaviour, since that
prevents a,b and c to become members of the same equivalence class.
Sorry for the spam on the list.

regards,
Yeb Havinga