Re: An obsolete comment of pg_stat_statements - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: An obsolete comment of pg_stat_statements
Date
Msg-id 20211224.153210.47060871929261388.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: An obsolete comment of pg_stat_statements  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: An obsolete comment of pg_stat_statements
List pgsql-hackers
At Mon, 22 Nov 2021 22:50:04 +0800, Julien Rouhaud <rjuju123@gmail.com> wrote in 
> On Mon, Nov 22, 2021 at 2:48 PM Kyotaro Horiguchi
> <horikyota.ntt@gmail.com> wrote:
> >
> > At Mon, 22 Nov 2021 15:38:23 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in
> > >  * queryId is supposed to be a valid value, otherwise this function dosen't
> > >  * calucate it by its own as before then returns immediately.
> >
> > Mmm. That's bad. This is the correted version.
> >
> >  * queryId is supposed to be a valid value, otherwise this function doesn't
> >  * calculate it by its own as before then returns immediately.
> 
> Ah good catch!  Indeed the semantics changed and I missed that comment.
> 
> I think that the new comment should be a bit more precise about what
> is a valid value and should probably not refer to a previous version
> of the code.  How about something like:
> 
> - * 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 queryId is 0 then no query fingerprinting source has been enabled, so we
> + * act as if the extension was disabled: silently exit without doing any work.
>   *

Thanks! Looks better.  It is used as-is in the attached.

And I will register this to the next CF.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center
From 1563bd869cb8da080e3488e64116da402f79be8c Mon Sep 17 00:00:00 2001
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Date: Fri, 24 Dec 2021 15:25:57 +0900
Subject: [PATCH] Fix a function comment

Commit 5fd9dfa5f50e4906c35133a414ebec5b6d518493 forgot to fix the
comment. Fix it so that it desribes the new behavior.

Author: Julien Rouhaud
Reviewed-by: Kyotaro Horiguchi
---
 contrib/pg_stat_statements/pg_stat_statements.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/contrib/pg_stat_statements/pg_stat_statements.c b/contrib/pg_stat_statements/pg_stat_statements.c
index 726ba59e2b..3224da9275 100644
--- a/contrib/pg_stat_statements/pg_stat_statements.c
+++ b/contrib/pg_stat_statements/pg_stat_statements.c
@@ -1191,9 +1191,8 @@ 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 queryId is 0 then no query fingerprinting source has been enabled, so we
+ * act as if the extension was disabled: silently exit without doing any work.
  *
  * 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
-- 
2.27.0


pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: Be clear about what log_checkpoints emits in the documentation
Next
From: Tomas Vondra
Date:
Subject: Re: sequences vs. synchronous replication