Re: SQL/JSON in PostgreSQL

Sven R. Kunze <srkunze@mail.de>

From: "Sven R. Kunze" <srkunze@mail.de>
To: Magnus Hagander <magnus@hagander.net>, Peter van Hardenberg <pvh@pvh.ca>
Cc: Andres Freund <andres@anarazel.de>, Oleg Bartunov <obartunov@gmail.com>, 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-09T18:12:07Z
Lists: pgsql-hackers
On 08.03.2017 20:52, Magnus Hagander wrote:
> On Wed, Mar 8, 2017 at 11:48 AM, Peter van Hardenberg <pvh@pvh.ca 
> <mailto:pvh@pvh.ca>> wrote:
>
>     Small point of order: YAML is not strictly a super-set of JSON.
>
>     Editorializing slightly, I have not seen much interest in the
>     world for YAML support though I'd be interested in evidence to the
>     contrary.
>
>
> The world of configuration management seems to for some reason run off 
> YAML, but that's the only places I've seen it recently (ansible, 
> puppet etc).

SaltStack uses YAML for their tools, too. I personally can empathize 
with them (as a user of configuration management) about this as writing 
JSON would be nightmare with all the quoting, commas, curly braces etc. 
But that's my own preference maybe.

(Btw. does "run off" mean like or avoid? At least my dictionaries tend 
to the latter.)

> That said if we're introducing something new, it's usually better to 
> copy from another format than to invite your own.

 From my day-to-day work I can tell, the date(time) type is the only 
missing piece of JSON to make it perfect for business applications 
(besides, maybe, a "currency" type).

Regards,
Sven

Commits

  1. SQL/JSON: support the IS JSON predicate

  2. SQL/JSON: add standard JSON constructor functions