aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils/adt/float.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2018-04-20 15:19:17 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2018-04-20 15:19:17 -0400
commit80e12a6218761f444d1dae38c9545b9b18c48f18 (patch)
treeb696c717b74820972a8b78fa5e9a50c287851fbf /src/backend/utils/adt/float.c
parente4e43a16b250abd9c4d3431d4824f7150ee74bec (diff)
downloadpostgresql-80e12a6218761f444d1dae38c9545b9b18c48f18.tar.gz
postgresql-80e12a6218761f444d1dae38c9545b9b18c48f18.zip
Change more places to be less trusting of RestrictInfo.is_pushed_down.
On further reflection, commit e5d83995e didn't go far enough: pretty much everywhere in the planner that examines a clause's is_pushed_down flag ought to be changed to use the more complicated behavior where we also check the clause's required_relids. Otherwise we could make incorrect decisions about whether, say, a clause is safe to use as a hash clause. Some (many?) of these places are safe as-is, either because they are never reached while considering a parameterized path, or because there are additional checks that would reject a pushed-down clause anyway. However, it seems smarter to just code them all the same way rather than rely on easily-broken reasoning of that sort. In support of that, invent a new macro RINFO_IS_PUSHED_DOWN that should be used in place of direct tests on the is_pushed_down flag. Like the previous patch, back-patch to all supported branches. Discussion: https://postgr.es/m/f8128b11-c5bf-3539-48cd-234178b2314d@proxel.se
Diffstat (limited to 'src/backend/utils/adt/float.c')
0 files changed, 0 insertions, 0 deletions