ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes: > Tom Lane <t...@sss.pgh.pa.us> writes: > >> ilm...@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