On Tue, Oct 3, 2017 at 11:55 PM, Robert Haas <robertmh...@gmail.com> wrote: > It seems silly to me to throw away a perfectly good bit from the hash > value just because of some risk of minor user confusion. I do like > Michael's suggestion of outputing hexa-like text, but changing the > types of the user-visible output columns seems like a job for another > patch. Similarly, if we were to adopt Andres's suggestions of a new > type or using numeric or Alexander's suggestion of implementing a > 64-bit unsigned type, I think it should be a separate patch from this > one.
Yeah, any of them would require a version bump of pg_stat_statements. My suggestion would be actually to just document the use of to_hex in pg_stat_statements if there is any issue with query ID signed-ness. Still, I have yet to see any user stories about complains on the matter, so even just added a note in the docs may be overdoing it. Thinking about that freshly today (new day, new thoughts of course), I think that I would go with the 64-bit version. The patch gets more simple, and there are ways to easily get around negative numbers by applying anything like to_hex() on top of pg_stat_statements. +/* Write an unsigned integer field (anything written with UINT64_FORMAT) */ +#define WRITE_UINT64_FIELD(fldname) \ + appendStringInfo(str, " :" CppAsString(fldname) " " UINT64_FORMAT, \ + node->fldname) Correct call here. { - return hash_any((const unsigned char *) str, len); + return hash_any_extended((const unsigned char *) str, len, 0); } [...] - uint32 start_hash = hash_any(jumble, JUMBLE_SIZE); + uint64 start_hash = hash_any_extended(jumble, JUMBLE_SIZE, 0); Missing two DatumGetUInt64() perhaps? HEAD looks wrong to me as well. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers