Re: SQL/JSON: documentation

From: Chapman Flack <chap(at)anastigmatix(dot)net>
To: Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Cc: Liudmila Mantrova <l(dot)mantrova(at)postgrespro(dot)ru>, Oleg Bartunov <obartunov(at)gmail(dot)com>
Subject: Re: SQL/JSON: documentation
Date: 2018-06-28 23:16:21
Message-ID: ff0ed606-645a-88a9-d4b3-e18b4bb0d01f@anastigmatix.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 06/28/2018 06:45 PM, Nikita Glukhov wrote:

> Standard says only about returning of string (both binary and character),
> numeric, boolean and datetime types in JSON_VALUE and only about string
> types in JSON_QUERY.

What I think I noticed was that right now, in func-sqljson.sgml,
the same list of seven types (not including numeric, boolean, or
datetime) is repeated for both JSON_QUERY and JSON_VALUE. Should
the list for JSON_VALUE also mention that numeric, boolean, and
datetime are supported there? That's the description that is near
line 1067.

> Arithmetic operations in jsonpath are implemented using PG numeric
> datatype,
> which also is used in jsonb for representation of JSON numbers:
> ...
> =# SELECT jsonb '-3.4' @* '$ % 2.3';
>  ?column?
> ----------
>  -1.1

In a recent message[1] it seemed that PG itself relies on the
underlying C compiler behavior, at least for int and float, which
could mean that on some platforms the answer is -1.1 and on others
+1.2. But I don't know whether that is true for PG numeric, since
that is implemented much more within PG itself, so perhaps it has
a platform-independent behavior. The XQuery result would be -1.1 on
all platforms, because the standard is explicit there.

-Chap

[1]: https://www.postgresql.org/message-id/23660.1530070402%40sss.pgh.pa.us

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-06-28 23:18:36 Re: Fix to not check included columns in ANALYZE on indexes
Previous Message David Rowley 2018-06-28 23:10:53 Re: Generating partitioning tuple conversion maps faster