Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements

Julien Rouhaud <rjuju123@gmail.com>

From: Julien Rouhaud <rjuju123@gmail.com>

To: Andrei Zubkov <zubkov@moonset.ru>

Cc: Greg Stark <stark@mit.edu>, Andres Freund <andres@anarazel.de>, "Anton A. Melnikov" <aamelnikov@inbox.ru>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>

Date: 2022-04-03T09:56:16Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Improve quoting in some error messages
- 07e5e6674233 14.0 cited

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.