On 03/12/2016 04:47 PM, Tom Lane wrote:
> Salvador Fandiño <sfandino@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".
