Tom Lane <t...@sss.pgh.pa.us> writes: > ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes: >> Tom Lane <t...@sss.pgh.pa.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
>From cf5771f98aa33bc7f12054d65857a3cc347465dc Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dagfinn=20Ilmari=20Manns=C3=A5ker?= <ilm...@ilmari.org> Date: Tue, 10 Apr 2018 10:57:50 +0100 Subject: [PATCH] Fix clashing function names bettween jsonb_plperl and jsonb_plperlu --- contrib/jsonb_plperl/jsonb_plperlu--1.0.sql | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/contrib/jsonb_plperl/jsonb_plperlu--1.0.sql b/contrib/jsonb_plperl/jsonb_plperlu--1.0.sql index 99b8644e3b..5a5e475ad3 100644 --- a/contrib/jsonb_plperl/jsonb_plperlu--1.0.sql +++ b/contrib/jsonb_plperl/jsonb_plperlu--1.0.sql @@ -3,17 +3,17 @@ -- complain if script is sourced in psql, rather than via CREATE EXTENSION \echo Use "CREATE EXTENSION jsonb_plperlu" to load this file. \quit -CREATE FUNCTION jsonb_to_plperl(val internal) RETURNS internal +CREATE FUNCTION jsonb_to_plperlu(val internal) RETURNS internal LANGUAGE C STRICT IMMUTABLE -AS 'MODULE_PATHNAME'; +AS 'MODULE_PATHNAME', 'jsonb_to_plperl'; -CREATE FUNCTION plperl_to_jsonb(val internal) RETURNS jsonb +CREATE FUNCTION plperlu_to_jsonb(val internal) RETURNS jsonb LANGUAGE C STRICT IMMUTABLE -AS 'MODULE_PATHNAME'; +AS 'MODULE_PATHNAME', 'plperl_to_jsonb'; CREATE TRANSFORM FOR jsonb LANGUAGE plperlu ( - FROM SQL WITH FUNCTION jsonb_to_plperl(internal), - TO SQL WITH FUNCTION plperl_to_jsonb(internal) + FROM SQL WITH FUNCTION jsonb_to_plperlu(internal), + TO SQL WITH FUNCTION plperlu_to_jsonb(internal) ); COMMENT ON TRANSFORM FOR jsonb LANGUAGE plperlu IS 'transform between jsonb and Perl'; -- 2.17.0