| From: | Staroverov Ilja <i(dot)staroverov(at)ftdata(dot)ru> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Sami Imseih <samimseih(dot)pg(at)gmail(dot)com>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: pg_stat_statements replaces SQL/JSON ON EMPTY / ON ERROR keywords with parameters |
| Date: | 2026-10-22 10:52:28 |
| Message-ID: | 83202E93-9039-410B-B4F2-A141DD7D80E1@localhost.localdomain |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Hi Michael,
Thanks for expanding and committing the tests.
> No backpatch can happen on that, I am afraid.
Understood.
Attached is v5, rebased on top of ae75d12b5, without the tests patch.
The only code change since v4 is in makeJsonTablePathScan() in 0002,
which now gets the location of the path from pathspec->location.
> but it's confusing to replace the
> NULL/DEFAULT/EMPTY by dollar parameters. And we have quite a few more
> of these incorrect patterns.
0001 fixes all of them in the new tests, for example:
$1 $2 ON EMPTY ERROR ON ERROR
-> $1 NULL ON EMPTY ERROR ON ERROR
$1 $2 ARRAY ON EMPTY $3 OBJECT ON ERROR
-> $1 EMPTY ARRAY ON EMPTY EMPTY OBJECT ON ERROR
and the three "JSON_EXISTS(js, $1 $2 ON ERROR)" entries become TRUE,
FALSE and UNKNOWN ON ERROR. The entries and their call counts stay the
same, only the texts change. After 0001, the only parameter symbols
left in the ON EMPTY and ON ERROR clauses are the DEFAULT values, as
in "DEFAULT $2 ON EMPTY", where $2 is the value itself (1 or 2 in the
tests), a constant in the query text.
0002 is the JSON_TABLE jumbling. Its diff shows the merged entries
being split: for example, the ten queries with different column types
and behaviors were in a single entry, and so were the thirteen with
EXISTS, FORMAT JSON and FOR ORDINALITY columns. Queries with
equivalent plans are still merged: the one without a PLAN clause with
PLAN (p0 OUTER (p1 UNION p2)), and PLAN (p0 INNER (p1 UNION p2)) with
PLAN DEFAULT (INNER) and PLAN DEFAULT (UNION, INNER). So are queries
that differ only in column names, path names, or PATH after NESTED.
The exception is columns without PATH, as in "COLUMNS (a int)" and
"COLUMNS (b int)": their paths are derived from the names, so the
names are part of the query ID in that case.
One split in that diff may look unnecessary: "a jsonb PATH" and
"a jsonb FORMAT JSON PATH". Their JsonExprs differ only in the format
of the RETURNING clause, as do JSON_QUERY(js, '$' RETURNING jsonb) and
the same with FORMAT JSON, which already get different query IDs, so
I left that alone.
--
Ilya Staroverov
| Attachment | Content-Type | Size |
|---|---|---|
| v5-0001-Don-t-give-the-SQL-JSON-behavior-constants-a-loca.patch | application/octet-stream | 9.0 KB |
| v5-0002-Include-JSON_TABLE-column-definitions-in-query-ju.patch | application/octet-stream | 22.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nitin Motiani | 2026-10-22 13:00:04 | Re: BUG #19767: pg_get_viewdef prints ORDER BY (- '3'::int4) as (- 3), which reparses as column position -3 |
| Previous Message | Zhijie Hou | 2026-10-22 08:53:41 | Re: BUG #19760: CLUSTER loses a row the transaction inserted and then updated in a rolled-back subtransaction |