=?UTF-8?Q?Salvador_Fandi=c3=b1o?= writes:
> On 03/12/2016 04:47 PM, Tom Lane wrote:
>> 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
On 03/12/2016 04:47 PM, Tom Lane wrote:
=?UTF-8?Q?Salvador_Fandi=c3=b1o?= 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
=?UTF-8?Q?Salvador_Fandi=c3=b1o?= 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
On 03/12/2016 12:49 AM, Tom Lane wrote:
Anybody know what will happen when passing a uint64 to newSViv()?
On 64 bit platforms, it is just interpreted as a signed integer, any
number with the upper bit set will become negative. Perl provides
newSVuv for unsigned numbers.
On 32bit platforms
On 03/11/2016 06:49 PM, Tom Lane wrote:
Anybody know what will happen when passing a uint64 to newSViv()?
A perl IV is guaranteed large enough to hold a pointer, if that's any
help. But for an unsigned value you might be better off calling newSVuv()
cheers
I wrote:
> Anybody know what will happen when passing a uint64 to newSViv()?
Oh, and how about Python's PyInt_FromLong()?
Or PyList_New()?
Or the second argument of PyList_SetItem()?
regards, tom lane
--
Sent via pgsql-hackers mailing list
Anybody know what will happen when passing a uint64 to newSViv()?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers