MDEV-35168 subselects with outer references to derived tables may be … #4584
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
…incorrectly evaluated as constant
Subselects with outer references to derived tables may be incorrectly evaluated as having no table references. This can lead to these subselects being marked as constant, leading to an incorrect result.
During the calculation of the tables used in a subselect, we construct a table map of outer references in our (not necessarily new) "new_parent" select. This is currently done purely by finding Item_fields in our tree and using the attached table to update our bitmap. It can be that a reference to a derived table also needs to have it's table added to this map. If the derived table can be null, this is the case.
We add a new processor to our item walk system,
enumerate_table_refs_processor which is defined at this stage only for Item_direct_view_ref items.
This called alongside enumerate_field_refs_processor in Item_subselect::recalc_used_tables().