postgres.git / summary / log / commit / refs

commit    e3b2c651bcd3230674ea4ea31c987474a00a1c98
Author:   Tom Lane <tgl@sss.pgh.pa.us>
Date:     Sat Sep 14 15:42:31 2024 +0000
First released in: 18.0, 17.0

    Remove obsolete comment in pg_stat_statements.
    
    Commit 76db9cb63 removed the use of multiple nesting counters,
    but missed one comment describing that arrangement.
    
    Back-patch to v17 where 76db9cb63 came in, just to avoid confusion.
    
    Julien Rouhaud
    
    Discussion: https://postgr.es/m/gfcwh3zjxc2vygltapgo7g6yacdor5s4ynr234b6v2ohhuvt7m@gr42joxalenw


 contrib/pg_stat_statements/pg_stat_statements.c | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/contrib/pg_stat_statements/pg_stat_statements.c b/contrib/pg_stat_statements/pg_stat_statements.c
index d4197ae0f7e..12718dfe45c 100644
--- a/contrib/pg_stat_statements/pg_stat_statements.c
+++ b/contrib/pg_stat_statements/pg_stat_statements.c
@@ -887,13 +887,6 @@ pgss_planner(Query *parse,
 	 * We can't process the query if no query_string is provided, as
 	 * pgss_store needs it.  We also ignore query without queryid, as it would
 	 * be treated as a utility statement, which may not be the case.
-	 *
-	 * Note that planner_hook can be called from the planner itself, so we
-	 * have a specific nesting level for the planner.  However, utility
-	 * commands containing optimizable statements can also call the planner,
-	 * same for regular DML (for instance for underlying foreign key queries).
-	 * So testing the planner nesting level only is not enough to detect real
-	 * top level planner call.
 	 */
 	if (pgss_enabled(nesting_level)
 		&& pgss_track_planning && query_string


[parent: 54497e0ed867]