Re: BUG #5084: Query gives different number of rows depending on ORDER BY

>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

Tom> I'm inclined to think that the best solution is to have
Tom> process_equivalence just reject any clauses that have equal()
Tom> left and right sides, ie, throw them back to be processed as
Tom> ordinary non-equivalence clauses.

>> Hmm. Is it ever possible for mergejoinable operators to be
>> non-strict? Does that matter?

Tom> I'm not sure. ISTR that nodeMergejoin makes some effort to
Tom> support such operators, but the btree code doesn't really. In
Tom> any case, it doesn't matter. Leaving the clause out of the
Tom> equivalence machinery is certainly safe; at worst we'll end up
Tom> with a redundant test or two in the final plan.

Yeah, and clearly leaving in that kind of redundant test is no big
deal.

--
Andrew (irc:RhodiumToad)