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

>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.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)