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

> On Wed, Jan 14, 2026 at 04:13:48PM -0600, Sami Imseih wrote:
> 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.

It has less to do with the order, the problem is that we have the
expression end location only for arrays. As far as I recall it was an
intentional design decision, and to adjust newa->list_end in such
scenarios we need to solve the original problem of finding an end
location of any arbitrary expression, which turned out to be
complicated. That's why I mention that tracking vars is more practical.

Nevertheless it makes sense to comment that in the code, just in case if
we're out of luck, and similar situation will appear somewhere else.

> ```
> 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.

It is, the proposed change helps to avoid the crash pointed out in this
thread. It might not be the right solution for the reasons discussed so
far, but as a general defensive mechanism makes total sense to me (maybe
with an assert to highlight any potential future problem).