From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Subject: | Re: Cleanup: remove unused fields from nodes |
Date: | 2024-04-23 17:01:04 |
Message-ID: | 3496529.1713891664@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Paquier <michael(at)paquier(dot)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 <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jacob Champion | 2024-04-23 17:02:10 | Re: Direct SSL connection with ALPN and HBA rules |
Previous Message | Andres Freund | 2024-04-23 16:59:39 | Re: gcc 12.1.0 warning |