Re: pg_stat_statements and "IN" conditions

> On Sun, Feb 05, 2023 at 11:02:32AM -0500, Tom Lane wrote:
> Dmitry Dolgov <9erthalion6(at)gmail(dot)com> writes:
> > I'm thinking about this in the following way: the core jumbling logic is
> > responsible for deriving locations based on the input expressions; in
> > the case of merging we produce less locations; pgss have to represent
> > the result only using locations and has to be able to differentiate
> > simple locations and locations after merging.
>
> Uh ... why? ISTM you're just going to elide all inside the IN,
> so why do you need more than a start and stop position?

Exactly, start and stop positions. But if there would be no information
that merging was applied, the following queries will look the same after
jumbling, right?

-- input query
SELECT * FROM test_merge WHERE id IN (1, 2);
-- jumbling result, two LocationLen, for values 1 and 2
SELECT * FROM test_merge WHERE id IN ($1, $2);

-- input query
SELECT * FROM test_merge WHERE id IN (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);
-- jumbling result, two LocationLen after merging, for values 1 and 10
SELECT * FROM test_merge WHERE id IN (...);
-- without remembering about merging the result would be
SELECT * FROM test_merge WHERE id IN ($1, $2);