aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gistutil.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2009-09-29 01:20:34 +0000
committerTom Lane <tgl@sss.pgh.pa.us>2009-09-29 01:20:34 +0000
commit25549edb268d5d02de16ce2cab33fee24c6d0873 (patch)
tree063b2b68e783c0bc1eaba79b4284013d22491306 /src/backend/access/gist/gistutil.c
parent176c3c8db95ee373c0fca412e395eb6a2499e660 (diff)
downloadpostgresql-25549edb268d5d02de16ce2cab33fee24c6d0873.tar.gz
postgresql-25549edb268d5d02de16ce2cab33fee24c6d0873.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/backend/access/gist/gistutil.c')
0 files changed, 0 insertions, 0 deletions