Michael Paquier <mich...@paquier.xyz> writes: > On Mon, Apr 22, 2024 at 06:46:27PM +0200, Matthias van de Meent wrote: >> On Mon, 22 Apr 2024 at 17:41, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> I think it would be a good idea to push 0003 for v17, just so nobody >>> grows an unnecessary dependency on that field. 0001 and 0005 could >>> be left for v18, but on the other hand they're so trivial that it >>> could also be sensible to just push them to get them out of the way.
> Tweaking the APIs should be OK until GA, as long as we agree that the > current interfaces can be improved. > 0003 is new in v17, so let's apply it now. I don't see much a strong > argument in waiting for the removal of 0001 and 0005, either, to keep > the interfaces cleaner moving on. However, this is not a regression > and these have been around for years, so I'd suggest for v18 to open > before moving on with the removal. I went ahead and pushed 0001 and 0003, figuring there was little point in waiting on 0001. I'd intended to push 0005 (remove "isall") as well, but it failed check-world: diff -U3 /home/postgres/pgsql/contrib/pg_stat_statements/expected/utility.out /home/postgres/pgsql/contrib/pg_stat_statements/results/utility.out --- /home/postgres/pgsql/contrib/pg_stat_statements/expected/utility.out 2023-12-08 15:14:55.689347888 -0500 +++ /home/postgres/pgsql/contrib/pg_stat_statements/results/utility.out 2024-04-23 12:17:22.187721947 -0400 @@ -536,12 +536,11 @@ SELECT calls, rows, query FROM pg_stat_statements ORDER BY query COLLATE "C"; calls | rows | query -------+------+---------------------------------------------------- - 2 | 0 | DEALLOCATE $1 - 2 | 0 | DEALLOCATE ALL + 4 | 0 | DEALLOCATE $1 2 | 2 | PREPARE stat_select AS SELECT $1 AS a 1 | 1 | SELECT $1 as a 1 | 1 | SELECT pg_stat_statements_reset() IS NOT NULL AS t -(5 rows) +(4 rows) SELECT pg_stat_statements_reset() IS NOT NULL AS t; That is, query jumbling no longer distinguishes "DEALLOCATE x" from "DEALLOCATE ALL", because the DeallocateStmt.name field is marked query_jumble_ignore. Now maybe that's fine, but it's a point we'd not considered so far in this thread. Thoughts? regards, tom lane