> On Mon, Jan 12, 2026 at 10:29:51PM -0600, Sami Imseih wrote:
> So, It is better to skip squashing altogether in this case. Attached is a
> patch.
>
> If there is agreement to this fix, I think it should be backpacthed to
> all versions that
> support squashing of IN-lists.
>
> Thoughts?
I think there are few important points:
* 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).
* 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.
* 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)
