Re: Transform for pl/perl

From: ilmari(at)ilmari(dot)org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=)
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Transform for pl/perl
Date: 2018-04-10 11:33:02
Message-ID: d8ja7ubjnyp.fsf@dalvik.ping.uio.no
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> ilmari(at)ilmari(dot)org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
>> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>>> I think you'd have to convert to text and back. That's kind of icky,
>>> but it beats failing.
>
>> I had a look, and that's what the PL/Python transform does. Attached is
>> a patch that does that for PL/Perl too, but only if the value is
>> actually > PG_INT64_MAX.
>
>> The secondary output files are for Perls with 32bit IV/UV types, but I
>> haven't been able to test them, since Debian's Perl uses 64bit integers
>> even on 32bit platforms.
>
> Ugh. I really don't want to maintain a separate expected-file for this,
> especially not if it's going to be hard to test. Can we choose another
> way of exercising the code path?

How about a plperl function that returns ~0 as numeric, and doing

select testuvtojsonb()::numeric = plperlu_maxuint();

in the test?

> Another issue with this code as written is that on 32-bit-UV platforms,
> at least some vompilers will give warnings about the constant-false
> predicate. Not sure about a good solution for that. Maybe it's a
> sufficient reason to invent uint8_numeric so we don't need a range check.

Yes, that does push the needle towards it being worth doing.

While playing around some more with the extension, I discoverered a few
more issues:

1) both the jsonb_plperl and jsonb_plperlu extensions contain the SQL
functions jsonb_to_plperl and plperl_to_jsonb, so can't be installed
simultaneously

2) jsonb scalar values are passed to the plperl function wrapped in not
one, but _two_ layers of references

3) jsonb numeric values are passed as perl's NV (floating point) type,
losing precision if they're integers that would fit in an IV or UV.

4) SV_to_JsonbValue() throws an error for infinite NVs, but not NaNs

Attached is a patch for the first issue. I'll look at fixing the rest
later this week.

- ilmari
--
"The surreality of the universe tends towards a maximum" -- Skud's Law
"Never formulate a law or axiom that you're not prepared to live with
the consequences of." -- Skud's Meta-Law

Attachment Content-Type Size
0001-Fix-clashing-function-names-bettween-jsonb_plperl-an.patch text/x-diff 1.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Finnerty 2018-04-10 11:41:32 Re: Custom PGC_POSTMASTER GUC variables ... feasible?
Previous Message Kyotaro HORIGUCHI 2018-04-10 11:13:05 Re: Boolean partitions syntax