From: | Anthony Bykov <a(dot)bykov(at)postgrespro(dot)ru> |
---|---|
To: | ilmari(at)ilmari(dot)org (Dagfinn Ilmari =?UTF-8?B?TWFubnPDpWtlcg==?=) |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-05-22 09:33:09 |
Message-ID: | 20180522123309.448ef797@anthony-24-g082ur |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 02 May 2018 17:41:38 +0100
ilmari(at)ilmari(dot)org (Dagfinn Ilmari Mannsåker) wrote:
> Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)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
Hello,
need any help with the patch?
--
Anthony Bykov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro HORIGUCHI | 2018-05-22 09:59:56 | Re: Time to put context diffs in the grave |
Previous Message | Kyotaro HORIGUCHI | 2018-05-22 09:20:20 | A Japanese-unfriendy error message contruction |