Re: pg_stat_statements replaces SQL/JSON ON EMPTY / ON ERROR keywords with parameters

On Mon, Oct 19, 2026 at 05:16:42AM +0000, Staroverov Ilja wrote:
> A correction to my previous message: it's not the number of columns
> that was part of the query ID, but the references to the columns from
> the rest of the query, such as the expansion of SELECT *. The commit
> message now says that.
>
> The test in 0002 now also checks that queries which differ only in
> column names or path names are merged, and that columns without PATH
> and with different names are not. The PLAN clause doesn't exist in
> REL_19_STABLE, so the test doesn't use it; I checked those cases on
> master by hand. The series applies to master and REL_19_STABLE, and
> I've tested it on both.

When it comes to such problems, I'd suggest to implement the tests as
a first patch, then do the jumbling logic in a second patch that shows
the changes in PGSS. It's easier to see what you think is the "wrong"
information and what becomes the "right" information ("wrong" and
"right" mean what you think is OK or not OK in terms of PGSS
monitoring).

+ 2 | SELECT * FROM JSON_TABLE($1::jsonb, $2 +
+ | COLUMNS (a int PATH $3 DEFAULT $4 ON EMPTY)) jt
+ 1 | SELECT * FROM JSON_TABLE($1::jsonb, $2 +
+ | COLUMNS (a int PATH $3)) jt
+ 2 | SELECT * FROM JSON_TABLE($1::jsonb, $2 +
+ | COLUMNS (a int PATH $3, +
+ | NESTED PATH $4 AS p1 COLUMNS (b int PATH $5))) jt
+ 1 | SELECT * FROM JSON_TABLE($1::jsonb, $2 +
+ | COLUMNS (a int)) jt
+ 1 | SELECT * FROM JSON_TABLE($1::jsonb, $2 +
+ | COLUMNS (a text PATH $3)) jt
+ 1 | SELECT * FROM JSON_TABLE($1::jsonb, $2 +
+ | COLUMNS (b int)) jt

There are many more keyword patterns than the ones tested here, like
PASSING, PLAN (UNION, OUTER ..), FORMAT JSON, etc. None of them are
covered. I guess that you may want to worry about them.

Instead of bloating more select.sql, let's move the JSON tests into a
different input file. They can be isolated, and there are way more
patterns than what you are showing here.

Note that none of this is backpatchable, as this impacts the Node
definitions and the query IDs computed.
--
Michael