From: ilmari@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=)
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,  Pavel Stehule <pavel.stehule@gmail.com>,
  Nikita Glukhov <n.gluhov@postgrespro.ru>,
  PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Transform for pl/perl
References: <20171127132439.23dc26ef@anthony-24-g082ur>
	<20171201184921.27he6vbp62yegpvm@alvherre.pgsql>
	<20171207125455.39067aa7@anthony-24-g082ur>
	<20171207125602.5326f103@anthony-24-g082ur>
	<CAEepm=02=Ya7p=-X5Of=JD-+9+bmmwnpd9nr8AeVnOopB6Y+NQ@mail.gmail.com>
	<20180112114739.6a9f0d4c@anthony-24-g082ur>
	<20180131103621.GA19345@zakirov.localdomain>
	<20180215125313.290468ae@anthony-24-g082ur>
	<CAFj8pRCYBPFGZG5LHdfY1Ej+a_9sb3ugyDkUaJGD37UjpRpA8Q@mail.gmail.com>
	<20180312110821.29c80420@anthony-24-g082ur>
	<CAFj8pRDaTYHD30CP8u2v_wwsJfxFBfthcNEp_KgEOHVN0gUfAw@mail.gmail.com>
	<505345c5-0159-077d-f64e-60afb01e5fbe@postgrespro.ru>
	<CAFj8pRB1mLEvmnhRL9HheF6yeKPvuzBf2tQ=s+2QXGpnCJdbqQ@mail.gmail.com>
	<26a0840a-6b09-44fc-9e4e-8200c1887882@2ndquadrant.com>
	<d8jtvskjzzs.fsf@dalvik.ping.uio.no>
	<d8jefjojudc.fsf@dalvik.ping.uio.no> <15075.1523287460@sss.pgh.pa.us>
	<d8ja7ubjnyp.fsf@dalvik.ping.uio.no>
	<cf26408a-c01f-03c4-5df3-edf2e81ef526@2ndquadrant.com>
Mail-Copies-To: nobody
Date: Wed, 02 May 2018 17:41:38 +0100
In-Reply-To: <cf26408a-c01f-03c4-5df3-edf2e81ef526@2ndquadrant.com> (Peter
	Eisentraut's message of "Mon, 30 Apr 2018 13:27:31 -0400")
Message-ID: <d8jzi1iau2l.fsf@dalvik.ping.uio.no>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Precedence: bulk

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:

> These two items are now outstanding:
>
> On 4/10/18 07:33, Dagfinn Ilmari Mannsåker wrote:
>> 2) jsonb scalar values are passed to the plperl function wrapped in not
>>    one, but _two_ layers of references
>
> I don't understand this one, or why it's a problem, or what to do about it.

It means that if you call a jsonb-transforming pl/perl function like

   select somefunc(jsonb '42');

it receives not the scalar 42, but reference to a reference to the
scalar (**int instead of an int, in C terms).  This is not caught by the
current round-trip tests because the output transform automatically
dereferences any number of references on the way out again.

The fix is to reshuffle the newRV() calls in Jsonb_to_SV() and
jsonb_to_plperl().  I am working on a patch (and improved tests) for
this, but have not have had time to finish it yet.  I hope be able to in
the next week or so.

>> 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.
>
> This seems fixable, but perhaps we need to think through whether this
> will result in other strange behaviors.

Nubers > 2⁵³ are not "interoperable" in the sense of the JSON spec,
because JavaScript only has doubles, but it seems desirable to preserve
whatever precision one reasonably can, and I can't think of any
downsides.  We already support the full numeric range when processing
JSONB in SQL, it's just in the PL/Perl transform (and possibly
PL/Python, I didn't look) we're losing precision.

Perl can also be configured to use long double or __float128 (via
libquadmath) for its NV type, but I think preserving 64bit integers when
building against a Perl with a 64bit integer type would be sufficient.

- 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