Hello.
I noticed obsolete lines in the function comment of pgss_store().
* If queryId is 0 then this is a utility statement for which we couldn't
* compute a queryId during parse analysis, and we should compute a suitable
* queryId internally.
Previously the function actually calculates queryId using
pgss_hash_string when the given queryId is 0, but since 14 the
function simply rejects to work. We can just drop the paragraph. Or
we can emphasize the change of the behavior by describing the current
behavior for the value.
The attached patch is doing the latter.
* queryId is supposed to be a valid value, otherwise this function dosen't
* calucate it by its own as before then returns immediately.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/contrib/pg_stat_statements/pg_stat_statements.c b/contrib/pg_stat_statements/pg_stat_statements.c
index 726ba59e2b..59291a8334 100644
--- a/contrib/pg_stat_statements/pg_stat_statements.c
+++ b/contrib/pg_stat_statements/pg_stat_statements.c
@@ -1191,10 +1191,6 @@ pgss_ProcessUtility(PlannedStmt *pstmt, const char *queryString,
/*
* Store some statistics for a statement.
*
- * If queryId is 0 then this is a utility statement for which we couldn't
- * compute a queryId during parse analysis, and we should compute a suitable
- * queryId internally.
- *
* If jstate is not NULL then we're trying to create an entry for which
* we have no statistics as yet; we just want to record the normalized
* query string. total_time, rows, bufusage and walusage are ignored in this
@@ -1202,6 +1198,9 @@ pgss_ProcessUtility(PlannedStmt *pstmt, const char *queryString,
*
* If kind is PGSS_PLAN or PGSS_EXEC, its value is used as the array position
* for the arrays in the Counters field.
+ *
+ * queryId is supposed to be a valid value, otherwise this function dosen't
+ * calucate it by its own as before then returns immediately.
*/
static void
pgss_store(const char *query, uint64 queryId,