Re: plpgsql arrays

On Fri, 3 Apr 2009, Tom Lane wrote:
>> Oh, hang on, I think I saw something in the docs about what conditions can
>> be used in a merge...
>
> No, you got it right the first time.  I was about to suggest that maybe
> you could make it work by recasting the problem as equality on an
> interval datatype, but the problem is that this is not equality but
> "overlaps".  And you can't cheat and call it equality, because it's
> not transitive.

Well, according to 
http://www.postgresql.org/docs/8.3/interactive/xoper-optimization.html#AEN41844

| So, both data types must be capable of being fully ordered, and the 
| join operator must be one that can only succeed for pairs of values that 
| fall at the "same place" in the sort order.

> I don't actually believe that a standard merge join algorithm will work
> with an intransitive join condition ...

A standard merge join should work absolutely fine, depending on how it's 
implemented. If the implementation keeps a list of "current" right-hand 
elements, and adds right-hand rows to the list when they compare "equal" 
to the current left-hand element, and removes them from the list when they 
compare "not equal" to the current left-hand element, then it would work 
fine. If it does something else like rewinding the right-hand stream, or 
throwing away the list when the current left-hand element is "not equal" 
the previous left-hand element, (which would be fine for true equality) 
then it will not work.

The description in the docs doesn't make it clear which way Postgres does 
it.

Matthew

-- 
 I have an inferiority complex. But it's not a very good one.