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

From David Rowley
Subject Re: Add comment explaining why queryid is int64 in pg_stat_statements
Date
Msg-id CAApHDvq_ArY9GXoGzH0DZQu9M5-qFfUqdjBExx-wau+HykhtUQ@mail.gmail.com
Whole thread Raw
In response to Re: Add comment explaining why queryid is int64 in pg_stat_statements  (Julien Rouhaud <rjuju123@gmail.com>)
List pgsql-hackers
On Tue, 20 May 2025 at 18:12, Julien Rouhaud <rjuju123@gmail.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



pgsql-hackers by date:

Previous
From: Aleksander Alekseev
Date:
Subject: Re: Should we optimize the `ORDER BY random() LIMIT x` case?
Next
From: Sami Imseih
Date:
Subject: Re: Regression in statement locations