Thread: pgsql: Fix equivclass.c's not-quite-right strategy for handling X=X
pgsql: Fix equivclass.c's not-quite-right strategy for handling X=X
From
tgl@postgresql.org (Tom Lane)
Date:
Log Message:
-----------
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.
Modified Files:
--------------
pgsql/src/backend/optimizer:
README (r1.51 -> r1.52)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/README?r1=1.51&r2=1.52)
pgsql/src/backend/optimizer/path:
equivclass.c (r1.20 -> r1.21)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/path/equivclass.c?r1=1.20&r2=1.21)
pgsql/src/test/regress/expected:
select.out (r1.20 -> r1.21)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/select.out?r1=1.20&r2=1.21)
pgsql/src/test/regress/sql:
select.sql (r1.15 -> r1.16)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/select.sql?r1=1.15&r2=1.16)