Re: Perl's newSViv() versus 64-bit ints?
От | Tom Lane |
---|---|
Тема | Re: Perl's newSViv() versus 64-bit ints? |
Дата | |
Msg-id | 14945.1457800721@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Perl's newSViv() versus 64-bit ints? (Salvador Fandiño <sfandino@gmail.com>) |
Список | pgsql-hackers |
Salvador Fandiño <sfandino@gmail.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
В списке pgsql-hackers по дате отправления: