From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Salvador Fandiño <sfandino(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Perl's newSViv() versus 64-bit ints? |
Date: | 2016-03-12 16:38:41 |
Message-ID: | 14945.1457800721@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
=?UTF-8?Q?Salvador_Fandi=c3=b1o?= <sfandino(at)gmail(dot)com> 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 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.
Sounds good. I notice that the manual discourages people from using
spi_exec_query() for "big" results, which means we could possibly get
away without doing anything here; but I'll feel better about it if we
can push the upper limit to 2^53 or so.
Given that text in the manual, I think it might be worth the code space
to do it like this:
(SPI_processed > INT_MAX) ? newSVnv(SPI_processed) : newSViv(SPI_processed)
since the NV code path is presumably a bit slower and it's very likely
that users would never actually need it.
I wonder whether this idea has analogues for python and tcl ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2016-03-12 16:56:00 | Re: [PROPOSAL] VACUUM Progress Checker. |
Previous Message | Tom Lane | 2016-03-12 16:25:31 | Re: Performance improvement for joins where outer side is unique |