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)