Thanks for the comments!
> * From what I understand the transformation that's causing this is
> exactly the one from transformAExprIn, and from that perspective
> refusing to squash if Vars are present is a reasonable approach (if
> they won't be splitted off, such Array will not pass
> IsSquashableConstantList anyway).
Correct. If a list had Vars exclusively, it will not be eligible for squashing.
> * I think one subtle thing, which we're doing wrong in transformAExprIn
> is splitting elements into rvars and rnonvars, but still using end
> location of the whole expression a->rexpr_list_end as the end location
> of the new array. This, together with an attempt to record a constant
> form the same range is ultimately causing the problem. Probably it
> would be a good idea to adjust newa->list_end with this in mind.
That crossed my mind, but I am not sure how we can actually do this
since we can have Vars and nonVars in different orders in the list.
```
SELECT * FROM test_squash a, test_squash b WHERE a.id IN (b.id + 1, 1,
b.id + 1, 3,
b.id, b.id + 1);
```
> * Independently from that, it sounds like a good idea to have protection
> from overlapping constants when generating normalized query. It could
> be done in the same way as the previous bug was fixed. In
> fill_in_constant_lengths we currently check for duplicated constants:
>
> locs[i].location == locs[i - 1].location
>
> then set length = -1 for those. I think it's worth extending it to
> check for overlapping with the previous constant, something like:
>
> (locs[i].location == locs[i - 1].location ||
> locs[i].location <= locs[i - 1].location + locs[i - 1].length)
Yeah, this may be a good defensive check to add, but it's
not going to be useful for this issue.
--
Sami Imseih
Amazon Web Services (AWS)
