ilmari@ilmari.org (Dagfinn Ilmari Mannsåker) writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> 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.
> IVs and UVs are semantically equivalent, and Perl will automatically
> convert between them (and NVs) as necessary, i.e. when crossing
> IV_MAX/UV_MAX/IV_MIN.
OK, thanks for the authoritative statement.
>> 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 ?
> There isn't, unfortunately.
Sigh ... it was worth asking anyway.
>>> 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.
> One hazard would be that people not heeding the warning in
> spi_exec_query will get a visit from the OOM killer (or death by swap)
> instead of a friendly "invalid memory alloc request size".
Yeah. But there are plenty of other ways to drive a backend into swap
hell, and the whole point of this change is to eliminate arbitrary
boundaries on query result size. So let's do it.
Thanks for the patch and discussion!
regards, tom lane
