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

From Nathan Bossart
Subject Re: Add comment explaining why queryid is int64 in pg_stat_statements
Date
Msg-id aDhvEzWlRl3sWEt4@nathan
Whole thread Raw
In response to Re: Add comment explaining why queryid is int64 in pg_stat_statements  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Add comment explaining why queryid is int64 in pg_stat_statements
List pgsql-hackers
On Thu, May 29, 2025 at 01:53:07PM +0900, Michael Paquier wrote:
> On Thu, May 22, 2025 at 01:01:14PM +0900, Michael Paquier wrote:
>> I have added an open item about the plan ID part as it applies to v18,
>> adding the RMT in CC to get an opinion.  If we cannot get a consensus
>> on all that, letting things as they are is still logically correct,
>> even with the -Wwarnings-format-signedness argument which is not
>> included by default currently.
>> 
>> Has somebody an opinion to offer?
> 
> It has been one week since this last update, and there has been
> nothing except the sound of cicadas.  IMO, I think that we should just
> pull the switch and make both of these IDs signed on HEAD, taking case
> of the potential signedness warning issues.
> 
> Now, I don't really want to take a leap of faith without the RMT being
> OK with that now that we are in beta1.

After reading through this thread and the latest patch set, I don't see any
strong reason for the RMT to object to this change for v18.  IIUC some
extensions may need to adapt, but we're still a few months from 18.0, so
that seems okay.  I vaguely recall that we've made other small
extension-breaking changes during the beta period for previous major
releases.

-- 
nathan



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them
Next
From: "David G. Johnston"
Date:
Subject: Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them