From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Nikita Glukhov <n.gluhov@postgrespro.ru>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Transform for pl/perl
Date: Thu, 17 May 2018 17:11:23 -0400
Message-ID: <20180517211123.wrml3yvrl3b2rmrq@alvherre.pgsql> (raw)
In-Reply-To: <d8jzi1iau2l.fsf@dalvik.ping.uio.no>
Hello
This is still listed as an open item, though the patch proposed by Peter
upthread has been committed. If I understand correctly, ilmari was
going to propose another patch. Or is the right course of action to set
the open item as resolved?
On 2018-May-02, Dagfinn Ilmari Mannsåker wrote:
> 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
>
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: alvherre@2ndquadrant.com, ilmari@ilmari.org, peter.eisentraut@2ndquadrant.com, tgl@sss.pgh.pa.us, pavel.stehule@gmail.com, n.gluhov@postgrespro.ru, pgsql-hackers@lists.postgresql.org
Subject: Re: Transform for pl/perl
In-Reply-To: <20180517211123.wrml3yvrl3b2rmrq@alvherre.pgsql>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox