On Mon, Apr 12, 2021 at 10:12:46PM -0400, Bruce Momjian wrote:
> On Thu, Apr 8, 2021 at 01:01:42PM -0400, Bruce Momjian wrote:
> > On Thu, Apr 8, 2021 at 12:51:06PM -0400, Álvaro Herrera wrote:
> > > On 2021-Apr-08, Bruce Momjian wrote:
> > >
> > > > pg_stat_activity.queryid is new, but I can imagine cases where you would
> > > > join pg_stat_activity to pg_stat_statements to get an estimate of how
> > > > long the query will take --- having one using an underscore and another
> > > > one not seems odd.
> > >
> > > OK. So far, you have one vote for queryid (your own) and two votes for
> > > query_id (mine and Julien's). And even yourself were hesitating about
> > > it earlier in the thread.
> >
> > OK, if people are fine with pg_stat_activity.query_id not matching
> > pg_stat_statements.queryid, I am fine with that. I just don't want
> > someone to say it was a big mistake later. ;-)
>
> OK, the attached patch renames pg_stat_activity.queryid to 'query_id'. I
> have not changed any of the APIs which existed before this feature was
> added, and are called "queryid" or "queryId" --- it is kind of a mess.
> I assume I should leave those unchanged. It will also need a catversion
> bump.
- uint64 st_queryid;
+ uint64 st_query_id;
I thought we would internally keep queryid/queryId, at least for the variable
names as this is the name of the saved field in PlannedStmt.
-extern void pgstat_report_queryid(uint64 queryId, bool force);
+extern void pgstat_report_query_id(uint64 queryId, bool force);
But if we don't then it should be "uint64 query_id".
