| From: | Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com> |
|---|---|
| To: | Shaik Mohammad Mujeeb <mujeeb(dot)sk(at)zohocorp(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Cc: | mujeebskdev <mujeeb(dot)sk(dot)dev(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Add comment explaining why queryid is int64 in pg_stat_statements |
| Date: | 2025-05-16 09:42:41 |
| Message-ID: | f39083a0-9e2d-46a5-9b72-9fef8f87c3a6@tantorlabs.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 15.05.2025 10:08, Shaik Mohammad Mujeeb wrote:
> Hi Developers,
>
> In pg_stat_statements.c, the function /pg_stat_statements_internal()/
> declares the /queryid/ variable as *int64*, but assigns it a value of
> type *uint64*. At first glance, this might appear to be an overflow
> issue. However, I think this is intentional - the queryid is cast to
> /int64/ *to match the bigint type of the queryid column in the
> pg_stat_statements view*.
>
> Please find the attached patch, which adds a clarifying comment to
> make the rationale explicit and avoid potential confusion for future
> readers.
>
>
>
> Thanks and Regards,
> Shaik Mohammad Mujeeb
> Member Technical Staff
> Zoho Corp
>
>
I don't think the comment is necessary here. There are no arithmetic or
logical operations performed on it. It is only passed as a Datum.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | shveta malik | 2025-05-16 10:12:58 | Re: Conflict detection for update_deleted in logical replication |
| Previous Message | Amit Kapila | 2025-05-16 09:10:26 | Re: Conflict detection for update_deleted in logical replication |