On 03/12/2016 04:47 PM, Tom Lane wrote:
=?UTF-8?Q?Salvador_Fandi=c3=b1o?= <sfand...@gmail.com> writes:
Another possibility is to just use newSVnv(), but NVs are not
able to represent all the uint64 range precisely (IIRC, they can
represent integers up to 48bits?).
[ looks... ] Oh, NV is a "double", which I think would be a perfectly
reasonable choice: it'd be exact up to about 2^53, on most machines,
which should be plenty for a long time to come.
How much of a user-visible change would that be, if the "processed"
field of a spi_exec_query() result started coming back as an NV not
an IV? I'm not sure how much that would affect semantics in typical
Perl code.
At the Perl level, IVs and NVs are mostly indistinguishable, and Perl
does promote values internally from IVs to NVs to avoid overflows
automatically.
There are some operations that cause an implicit coercion from NV to IV
(or UV) under the hood, and in those cases, big values would get
mangled. For instance, bit operations as <<, >> or ~, or calling pack or
printf with some integer template do that.
Those don't look like common operations for "processed".
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
