From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Lukas Fittl <lukas(at)fittl(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Shaik Mohammad Mujeeb <mujeeb(dot)sk(at)zohocorp(dot)com>, ilyaevdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, 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-20 11:28:17 |
Message-ID: | CAApHDvq_ArY9GXoGzH0DZQu9M5-qFfUqdjBExx-wau+HykhtUQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 20 May 2025 at 18:12, Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
> I don't think it was discussed, but why not go the other way, keep everything
> as uint64 and expose an uint64 datatype at the SQL level instead? That's
> something I actually want pretty often so I would be happy to have that
> natively, whether it's called bigoid, oid8 or anything else. That's probably
> too late for pg18 though.
Certainly, a bit late, yes. It basically requires implementing
unsigned types on the SQL level. I believe there are a few sunken
ships along that coastline, and plenty of history in the archives if
you want to understand some of the difficulties.
David
From | Date | Subject | |
---|---|---|---|
Next Message | Sami Imseih | 2025-05-20 11:34:39 | Re: Regression in statement locations |
Previous Message | Aleksander Alekseev | 2025-05-20 10:46:38 | Re: Should we optimize the `ORDER BY random() LIMIT x` case? |