Horton

Re: SQL/JSON in PostgreSQL

Oleg Bartunov <obartunov@gmail.com>

View thread View on postgr.es
From: Oleg Bartunov <obartunov@gmail.com>
To: Petr Jelinek <petr.jelinek@2ndquadrant.com>
Cc: Peter van Hardenberg <pvh@pvh.ca>, "Sven R. Kunze" <srkunze@mail.de>, Robert Haas <robertmhaas@gmail.com>, Andres Freund <andres@anarazel.de>, David Steele <david@pgmasters.net>, Pavel Stehule <pavel.stehule@gmail.com>, Pgsql Hackers <pgsql-hackers@postgresql.org>, Nikita Glukhov <n.gluhov@postgrespro.ru>, Teodor Sigaev <teodor@postgrespro.ru>, Alexander Korotkov <a.korotkov@postgrespro.ru>, andrew Dunstan <andrew@dunslane.net>
Date: 2017-03-11T18:21:16Z
Lists: pgsql-hackers 
On Fri, Mar 10, 2017 at 7:07 AM, Petr Jelinek <petr.jelinek@2ndquadrant.com>
wrote:

> On 09/03/17 19:50, Peter van Hardenberg wrote:
> > Anecdotally, we just stored dates as strings and used a convention (key
> > ends in "_at", I believe) to interpret them. The lack of support for
> > dates in JSON is well-known, universally decried... and not a problem
> > the PostgreSQL community can fix.
> >
>
> The original complain was about JSON_VALUE extracting date but I don't
> understand why there is problem with that, the SQL/JSON defines that
> behavior. The RETURNING clause there is more or less just shorthand for
> casting with some advanced options.
>

There is no problem with serializing date and SQL/JSON describes it rather
well. There is no correct procedure to deserialize date from a correct json
string and the standards keeps silence about this and now we understand
that date[time] is actually virtual and the only use of them is in jsonpath
(filter) expressions.



>
> --
>   Petr Jelinek                  http://www.2ndQuadrant.com/
>   PostgreSQL Development, 24x7 Support, Training & Services
>

Commits

  1. SQL/JSON: support the IS JSON predicate

  2. SQL/JSON: add standard JSON constructor functions