From: ilmari@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=)
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
  Pavel Stehule <pavel.stehule@gmail.com>,
  Nikita Glukhov <n.gluhov@postgrespro.ru>,
  PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Transform for pl/perl
References: <20171127132439.23dc26ef@anthony-24-g082ur>
	<20171201184921.27he6vbp62yegpvm@alvherre.pgsql>
	<20171207125455.39067aa7@anthony-24-g082ur>
	<20171207125602.5326f103@anthony-24-g082ur>
	<CAEepm=02=Ya7p=-X5Of=JD-+9+bmmwnpd9nr8AeVnOopB6Y+NQ@mail.gmail.com>
	<20180112114739.6a9f0d4c@anthony-24-g082ur>
	<20180131103621.GA19345@zakirov.localdomain>
	<20180215125313.290468ae@anthony-24-g082ur>
	<CAFj8pRCYBPFGZG5LHdfY1Ej+a_9sb3ugyDkUaJGD37UjpRpA8Q@mail.gmail.com>
	<20180312110821.29c80420@anthony-24-g082ur>
	<CAFj8pRDaTYHD30CP8u2v_wwsJfxFBfthcNEp_KgEOHVN0gUfAw@mail.gmail.com>
	<505345c5-0159-077d-f64e-60afb01e5fbe@postgrespro.ru>
	<CAFj8pRB1mLEvmnhRL9HheF6yeKPvuzBf2tQ=s+2QXGpnCJdbqQ@mail.gmail.com>
	<26a0840a-6b09-44fc-9e4e-8200c1887882@2ndquadrant.com>
	<d8jtvskjzzs.fsf@dalvik.ping.uio.no>
	<d8jefjojudc.fsf@dalvik.ping.uio.no> <15075.1523287460@sss.pgh.pa.us>
	<d8ja7ubjnyp.fsf@dalvik.ping.uio.no> <17423.1523368349@sss.pgh.pa.us>
	<d8j604zjgtd.fsf@dalvik.ping.uio.no>
Date: Tue, 10 Apr 2018 15:31:28 +0100
In-Reply-To: <d8j604zjgtd.fsf@dalvik.ping.uio.no> ("Dagfinn Ilmari
	=?utf-8?Q?Manns=C3=A5ker=22's?= message of "Tue, 10 Apr 2018 15:07:26
 +0100")
Message-ID: <d8j1sfnjfpb.fsf@dalvik.ping.uio.no>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Precedence: bulk

ilmari@ilmari.org (Dagfinn Ilmari Mannsåker) writes:

> Tom Lane <tgl@sss.pgh.pa.us> writes:
>
>> ilmari@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
>>> While playing around some more with the extension, I discoverered a few
>>> more issues:
>>> ...
>>> 4) SV_to_JsonbValue() throws an error for infinite NVs, but not NaNs
>>
>> The others sound like bugs, but that one's intentional, since type
>> numeric does have a concept of NaN.  If you're arguing that we should
>> disallow that value in the context of jsonb, maybe so, but it'd likely
>> take changes in quite a few more places than here.
>
> The numeric type that's used internally to represent numbers in jsonb
> might have the concept of NaN, but JSON itself does not:
>
>     Numeric values that cannot be represented in the grammar below (such
>     as Infinity and NaN) are not permitted.
>
>       - https://tools.ietf.org/html/rfc7159#section-6
[…]
>    =# create or replace function jsonbnan() returns jsonb immutable language plperlu transform for type jsonb as '0+"NaN"';
>    CREATE FUNCTION
[…]
>    =# select jsonbnan()::json;
>    ERROR:  invalid input syntax for type json
>    DETAIL:  Token "NaN" is invalid.
>    CONTEXT:  JSON data, line 1: NaN

Also, it doesn't parse back in as jsonb either:

    =# select jsonbnan()::text::json;
    ERROR:  invalid input syntax for type json
    DETAIL:  Token "NaN" is invalid.
    CONTEXT:  JSON data, line 1: NaN

And it's inconsistent with to_jsonb():

    =# select to_jsonb('nan'::numeric);
    ┌──────────┐
    │ to_jsonb │
    ├──────────┤
    │ "NaN"    │
    └──────────┘

It would be highly weird if PL transforms (jsonb_plpython does the same
thing) let you create spec-violating jsonb values that don't round-trip
via jsonb_out/in.

- 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