ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) 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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers