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

Hi Michael,

Thanks for the review.

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

Done in the attached v4. 0001 adds a separate test file, sqljson.sql,
so select.sql is no longer touched. Besides the cases from v3, it
covers:

- the SQL/JSON query functions: ON EMPTY and ON ERROR behaviors,
RETURNING, PASSING, WRAPPER, QUOTES and FORMAT JSON;
- JSON_TABLE: column types and behaviors, EXISTS, FORMAT JSON and FOR
ORDINALITY columns, column and path names, NESTED PATH, PLAN with
OUTER/INNER and UNION/CROSS, PLAN DEFAULT, table-level ON ERROR and
PASSING;
- the SQL/JSON constructors and predicates: JSON_OBJECT, JSON_ARRAY,
JSON_OBJECTAGG, JSON_ARRAYAGG, JSON(), JSON_SCALAR, JSON_SERIALIZE
and IS JSON.

Its expected output shows the current behavior. 0002 is the behavior
keyword fix, and its diff of the expected output shows, for example,
"$2 ARRAY ON EMPTY" becoming "EMPTY ARRAY ON EMPTY", and three
identical "JSON_EXISTS(js, $1 $2 ON ERROR)" entries becoming TRUE,
FALSE and UNKNOWN ON ERROR. The new tests showed that the table-level
ON ERROR of JSON_TABLE was affected too, and 0002 fixes that as well.
0003 is the JSON_TABLE jumbling, and its diff shows the merged entries
being split: for example, eight queries with various column types and
behaviors were in a single entry, and so were PLAN (p0 OUTER p1) and
PLAN (p0 INNER p1). Each patch passes the tests on its own.

The constructors and predicates are fine as they are: queries that
differ in ABSENT ON NULL, WITH UNIQUE KEYS, RETURNING or FORMAT JSON
already get different query IDs, and the keywords are kept in the
normalized text.

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

Agreed for 0003. 0002 changes neither: it only leaves the location of
the behavior Consts unset, and locations are recorded, not hashed, so
the query IDs stay the same. But it's your call whether that's worth
back-patching.

--
Ilya Staroverov