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: