]> granicus.if.org Git - postgresql/commit
Fix equivclass.c's not-quite-right strategy for handling X=X clauses.
authorTom Lane <tgl@sss.pgh.pa.us>
Tue, 29 Sep 2009 01:21:02 +0000 (01:21 +0000)
committerTom Lane <tgl@sss.pgh.pa.us>
Tue, 29 Sep 2009 01:21:02 +0000 (01:21 +0000)
commit9cfc3d21661d21906cc3d235c53e9c1f5ceb8d77
treefe7f6733faa6d3f65510725343eff39262cf3388
parenteff805b588b07988d9072f8e371369cca6ecc523
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.
src/backend/optimizer/README
src/backend/optimizer/path/equivclass.c
src/test/regress/expected/select.out
src/test/regress/sql/select.sql