|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||ilmari(at)ilmari(dot)org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=)|
|Subject:||Re: [PATCH] Use correct types and limits for PL/Perl SPI query results|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
ilmari(at)ilmari(dot)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
|Next Message||Teodor Sigaev||2016-03-14 16:39:29||Re: proposal: function parse_ident|
|Previous Message||Artur Zakirov||2016-03-14 16:27:34||Re: Fuzzy substring searching with the pg_trgm extension|