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
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 |