Re: [PATCH] Use correct types and limits for PL/Perl SPI query results

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?=)
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] Use correct types and limits for PL/Perl SPI query results
Date: 2016-03-14 16:30:33
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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

In response to


Browse pgsql-hackers by date

  From Date Subject
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