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.
README (r1.41 -> r188.8.131.52)
equivclass.c (r184.108.40.206 -> r220.127.116.11)
select.out (r1.18 -> r18.104.22.168)
select.sql (r1.14 -> r22.214.171.124)
pgsql-committers by date
|Next:||From: User Eulerto||Date: 2009-09-29 03:38:34|
|Subject: pgspy - pgspy: Imported Sources|
|Previous:||From: Tom Lane||Date: 2009-09-29 01:20:55|
|Subject: pgsql: Fix equivclass.c's not-quite-right strategy for handling X=X |