Re: An obsolete comment of pg_stat_statements

Поиск
Список
Период
Сортировка
От Julien Rouhaud
Тема Re: An obsolete comment of pg_stat_statements
Дата
Msg-id CAOBaU_ZH-+M6FAD4K-0jc8+ddO9HgMddAv53xnoUn+Ms3A3vrw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: An obsolete comment of pg_stat_statements  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Ответы Re: An obsolete comment of pg_stat_statements  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Список pgsql-hackers
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.
  *



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dilip Kumar
Дата:
Сообщение: Re: row filtering for logical replication
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Windows build warnings