• T
    Fix equivclass.c's not-quite-right strategy for handling X=X clauses. · 9cfc3d21
    Tom Lane 提交于
    The original coding correctly noted that these aren't just redundancies
    (they're effectively X IS NOT NULL, assuming = is strict).  However, they
    got treated that way if X happened to be in a single-member EquivalenceClass
    already, which could happen if there was an ORDER BY X clause, for instance.
    The simplest and most reliable solution seems to be to not try to process
    such clauses through the EquivalenceClass machinery; just throw them back
    for traditional processing.  The amount of work that'd be needed to be
    smarter than that seems out of proportion to the benefit.
    
    Per bug #5084 from Bernt Marius Johnsen, and analysis by Andrew Gierth.
    9cfc3d21
README 31.9 KB