Fix equivclass.c's not-quite-right strategy for handling X=X clauses.
Tom Lane <tgl@sss.pgh.pa.us>
Fix equivclass.c's not-quite-right strategy for handling X=X clauses. 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.
Files
| Path | Change | +/− |
|---|---|---|
| src/backend/optimizer/path/equivclass.c | modified | +18 −8 |
| src/backend/optimizer/README | modified | +5 −2 |
| src/test/regress/expected/select.out | modified | +16 −0 |
| src/test/regress/sql/select.sql | modified | +5 −0 |