Closed svenklemm closed 4 months ago
What exactly is broken? I reproduced it but I have no idea what's going on... Theoretically, the make_restrictinfo
should take care of creating the proper orclause
as well.
What exactly is broken? I reproduced it but I have no idea what's going on... Theoretically, the
make_restrictinfo
should take care of creating the properorclause
as well.
Not yet sure what is going wrong there but the or branches are not wrapped in restrictinfos
It fixes the segfault but won't it create some perf regression?
Potentially yes. Ideally we can reenable this in followup PR after we fix OR processing.
Potentially yes. Ideally we can reenable this in followup PR after we fix OR processing.
Let's go with the thing we discussed on Slack -- avoiding nested AND boolexprs by applying eval_const_expressions
after modify_expression
in pushdown_quals
. I checked that it fixes this case.
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 80.83%. Comparing base (
59f50f2
) to head (5b9ffa0
). Report is 164 commits behind head on main.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
RestrictInfo with OR need special handling which we currently do not do which can lead to segfaults in planner if unhandled.
Fixes #6912