]> granicus.if.org Git - postgresql/commit
More fixes for lossy-GiST-distance-functions patch.
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 21 May 2015 23:47:48 +0000 (19:47 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 21 May 2015 23:47:48 +0000 (19:47 -0400)
commitc5dd8ead403f85bd041590d2e3e79b72830472d4
tree33bf4aa4143e930af0f5aadc3c894c0bb568d09c
parentd4b538ea367de43b2f2b939621272682417cd290
More fixes for lossy-GiST-distance-functions patch.

Paul Ramsey reported that commit 35fcb1b3d038a501f3f4c87c05630095abaaadab
induced a core dump on commuted ORDER BY expressions, because it was
assuming that the indexorderby expression could be found verbatim in the
relevant equivalence class, but it wasn't there.  We really don't need
anything that complicated anyway; for the data types likely to be used for
index ORDER BY operators in the foreseeable future, the exprType() of the
ORDER BY expression will serve fine.  (The case where we'd have to work
harder is where the ORDER BY expression's result is only binary-compatible
with the declared input type of the ordering operator; long before worrying
about that, one would need to get rid of GiST's hard-wired assumption that
said datatype is float8.)

Aside from fixing that crash and adding a regression test for the case,
I did some desultory code review:

nodeIndexscan.c was likewise overthinking how hard it ought to work to
identify the datatype of the ORDER BY expressions.

Add comments explaining how come nodeIndexscan.c can get away with
simplifying assumptions about NULLS LAST ordering and no backward scan.

Revert no-longer-needed changes of find_ec_member_for_tle(); while the
new definition was no worse than the old, it wasn't better either, and
it might cause back-patching pain.

Revert entirely bogus additions to genam.h.
src/backend/executor/nodeIndexscan.c
src/backend/optimizer/plan/createplan.c
src/include/access/genam.h
src/test/regress/expected/gist.out
src/test/regress/sql/gist.sql