Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view? - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?
Date
Msg-id 20210414183326.GA10946@momjian.us
Whole thread Raw
In response to Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?  (Julien Rouhaud <rjuju123@gmail.com>)
Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Tue, Apr 13, 2021 at 01:30:16PM -0400, Álvaro Herrera wrote:
> On 2021-Apr-12, Bruce Momjian wrote:
> 
> > 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.
> 
> I think it is fine actually.  These names appear in structs Query and
> PlannedStmt, and every single member of those already uses camelCase
> naming.  Changing those to use "query_id" would look out of place.
> You did change the one in PgBackendStatus to st_query_id, which also
> matches the naming style in that struct, so that looks fine also.
> 
> So I'm -1 on Julien's first proposed change, and +1 on his second
> proposed change (the name of the first argument of
> pgstat_report_query_id should be query_id).

Thanks for your analysis.  Updated patch attached with the change
suggested above.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  If only the physical world exists, free will is an illusion.


Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Possible typo/unclear comment in joinpath.c
Next
From: Andrew Dunstan
Date:
Subject: Re: Converting contrib SQL functions to new style