Re: Add comment explaining why queryid is int64 in pg_stat_statements
| От | Julien Rouhaud |
|---|---|
| Тема | Re: Add comment explaining why queryid is int64 in pg_stat_statements |
| Дата | |
| Msg-id | aCwdPY8WF36MjjEz@jrouhaud обсуждение исходный текст |
| Ответ на | Re: Add comment explaining why queryid is int64 in pg_stat_statements (Michael Paquier <michael@paquier.xyz>) |
| Ответы |
Re: Add comment explaining why queryid is int64 in pg_stat_statements
|
| Список | pgsql-hackers |
On Tue, May 20, 2025 at 02:09:13PM +0900, Michael Paquier wrote: > On Mon, May 19, 2025 at 08:43:25PM -0700, Lukas Fittl wrote: > > Yeah, +1 to making this consistent across both query ID and the new plan > > ID, and changing both to int64 internally seems best. > > Any thoughts from others? I'm OK to take the extra step of switching > both fields on HEAD and write a patch for that, relying on what David > has sent as a first step towards that. 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.
В списке pgsql-hackers по дате отправления: