Re: [[BUG] pg_stat_statements crashes with var and non-var expressions in IN clause

> 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)