diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2009-09-29 01:20:55 +0000 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2009-09-29 01:20:55 +0000 |
| commit | d4bd8423c9939a30f0f29e70745917e4635b4973 (patch) | |
| tree | b24b3603b30a15e731693fe8a84cdc672473a2d2 /src/include/executor | |
| parent | 38da75e1e9a592e27814f83c3166debf2686e3a1 (diff) | |
| download | postgresql-d4bd8423c9939a30f0f29e70745917e4635b4973.tar.gz postgresql-d4bd8423c9939a30f0f29e70745917e4635b4973.zip | |
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.
Diffstat (limited to 'src/include/executor')
0 files changed, 0 insertions, 0 deletions