On Mon, Oct 2, 2017 at 9:10 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Mon, Oct 2, 2017 at 11:02 AM, Joshua D. Drake <j...@commandprompt.com> > wrote: >> +1 to both of these as well. > > OK, so here's a patch. Review appreciated.
You need to change the SQL interface as well, although I'm not sure exactly how. The problem is that you are now passing a uint64 queryId to Int64GetDatumFast() within pg_stat_statements_internal(). That worked when queryId was a uint32, because you can easily represent values <= UINT_MAX as an int64/int8. However, you cannot represent the second half of the range of uint64 within a int64/int8. I think that this will behave different depending on USE_FLOAT8_BYVAL, if nothing else. The background here is that we used int8 as the output type for the function when queryId was first exposed via the SQL interface because there was no 32-bit unsigned int type that we could have used (except possibly Oid, but that's weird). You see the same pattern in a couple of other places. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
