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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Performance improvement for joins where outer side is unique
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: [PROPOSAL] VACUUM Progress Checker.