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
