ilmari@ilmari.org (Dagfinn Ilmari Mannsåker) writes:
> 1) Perl's integers are at least pointer-sized and either signed or
> unsigned, so can potentially hold up to 2⁶⁴-1. Floating point numbers
> can also be larger than double (up to 128bit), allowing for exact
> representation of integers beyond 2⁵³. Hence, adjust the setting of
> the "processed" hash item to use UV_MAX for the limit and (NV) or
> (UV) for the casts.
I thought about using UV where feasible, but it was not clear to me
whether unsigned numbers behave semantically differently from signed ones
in Perl. If they do, the change you suggest would create a small semantic
change in the behavior of code using spi_exec_query. I'm not sure it's
worth taking any risk of that, considering we already discourage people
from using spi_exec_query for large results.
> 2) Perl 5.20 and later use SSize_t for array indices, so can cope with
> up to SSize_t_max items in an array (if you have the memory).
I don't much like having such hard-wired knowledge about Perl versions
in our code. Is there a way to identify this change other than
#if PERL_BCDVERSION >= 0x5019004 ?
> 3) To be able to actually return such result sets from sp_exec_query(),
> I had to change the repalloc() in spi_printtup() to repalloc_huge().
Hmm, good point. I wonder if there are any hazards to doing that.
regards, tom lane
