Re: Add comment explaining why queryid is int64 in pg_stat_statements - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Add comment explaining why queryid is int64 in pg_stat_statements
Date
Msg-id aC1Z3yM7H8D90F-K@paquier.xyz
Whole thread Raw
In response to Re: Add comment explaining why queryid is int64 in pg_stat_statements  (Sami Imseih <samimseih@gmail.com>)
List pgsql-hackers
On Tue, May 20, 2025 at 10:35:39AM -0500, Sami Imseih wrote:
> 1/ this was missed in pg_stat_statements
> ./contrib/pg_stat_statements/pg_stat_statements.c:    uint64
> saved_queryId = pstmt->queryId;

Right.  Some greps based on "queryid" and "query_id" point that this
is the last reference to uint in the tree.

> 2/ Should "DatumGetInt64(hash_any_extended(......" be turned into a
> macro since it's used in
> several places? Also, we can add a comment in the macro such as
> "
> Output the queryId as an int64 rather than a uint64, to match the
> BIGINT column used to emit
> queryId in system views
> "

We are talking about two places in queryjumblefuncs.c.  Leaving the
code as in David's original proposal is fine IMO.  Adding a comment
about the implied uint64 -> int64 conversion when calling
hash_any_extended() sounds like a good idea to document what we want
from the hash.

I've had a closer look at David's patch, and I did not spot other
places that required similar adjustments.  I may have missed
something, of course.

David, how would you like to move on with this patch set?  I can take
responsibility for both patches as the plan ID change can qualify as
an open item.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: [BUG] Skipped initialization of some xl_xact_parsed_prepare fields
Next
From: Nisha Moond
Date:
Subject: Re: Fix slot synchronization with two_phase decoding enabled