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".
