Re: Transform for pl/perl - Mailing list pgsql-hackers

From ilmari@ilmari.org (Dagfinn Ilmari Mannsåker)
Subject Re: Transform for pl/perl
Date
Msg-id d8jtvskjzzs.fsf@dalvik.ping.uio.no
Whole thread Raw
In response to Re: Transform for pl/perl  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: Transform for pl/perl  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:

> On 3/15/18 03:46, Pavel Stehule wrote:
>> It looks well
>> 
>> the patch has tests and doc,
>> there are not any warnings or compilation issues
>> all tests passed
>> 
>> I'll mark this patch as ready for commiter
>
> committed

I played around with this a bit, and noticed that the number handling
doesn't cope with Perl UVs (unsigned integers) in the (IV_MAX, UV_MAX]
range:


    ilmari@[local]:5432 ~=# CREATE FUNCTION testUVToJsonb() RETURNS jsonb
    ilmari@[local]:5432 ~-# LANGUAGE plperl TRANSFORM FOR TYPE jsonb
    ilmari@[local]:5432 ~-# as $$
    ilmari@[local]:5432 ~$# $val = ~0;
    ilmari@[local]:5432 ~$# elog(NOTICE, "value is $val");
    ilmari@[local]:5432 ~$# return $val;
    ilmari@[local]:5432 ~$# $$;
    CREATE FUNCTION
    Time: 6.795 ms
    ilmari@[local]:5432 ~=# select testUVToJsonb();
    NOTICE:  value is 18446744073709551615
    ┌───────────────┐
    │ testuvtojsonb │
    ├───────────────┤
    │ -1            │
    └───────────────┘
    (1 row)

I tried fixing this by adding an 'if (SvUV(in))' clause to
SV_to_JsonbValue, but I couldn't find a function to create a numeric
value from an uint64.  If it's not possible, should we error on UVs
greater than PG_INT64_MAX?

- 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


pgsql-hackers by date:

Previous
From: Anthony Iliopoulos
Date:
Subject: Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS
Next
From: Tomas Vondra
Date:
Subject: Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS