Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements
Date
Msg-id 20220403095616.i6g6s5ub2z7ucctd@jrouhaud
Whole thread Raw
In response to Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements  (Andrei Zubkov <zubkov@moonset.ru>)
Responses Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements  (Andrei Zubkov <zubkov@moonset.ru>)
List pgsql-hackers
Hi,

On Sun, Apr 03, 2022 at 12:29:43PM +0300, Andrei Zubkov wrote:
> I've attached v12 of a patch. The only unsolved issue now is the
> following:
> 
> On Sun, 2022-04-03 at 15:07 +0800, Julien Rouhaud wrote:
> > +ALTER EXTENSION pg_stat_statements UPDATE TO '1.9';
> > +\d pg_stat_statements
> > +\d pg_stat_statements_info
> > +SELECT pg_get_functiondef('pg_stat_statements_reset'::regproc);
> > 
> > I don't think this bring any useful coverage.
> 
> It is a little bit unclear to me what is the best solution here.

Sorry, I missed that there were some similar tests already for previous
versions.  This was probably discussed and agreed before, so +1 to be
consistent with the new versions.

The patch looks good to me, although I will do a full review to make sure I
didn't miss anything.

Just another minor nitpicking after a quick look:

+ This field will be zero if ...
[...]
+ this field will contain zero until this statement ...

The wording should be consistent, so either "will be zero" or "will contain
zero" everywhere.  I'm personally fine with any, but maybe a native English
will think one is better.



pgsql-hackers by date:

Previous
From: Andrei Zubkov
Date:
Subject: Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements
Next
From: Andrei Zubkov
Date:
Subject: Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements