Re: extended operator classes vs. type interfaces

Robert Haas wrote:
> On Sat, Apr 10, 2010 at 12:05 PM, Yeb Havinga <yebhavinga@gmail.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