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
-
SQL/JSON: support the IS JSON predicate
- 6ee30209a6f1 16.0 landed
-
SQL/JSON: add standard JSON constructor functions
- 7081ac46ace8 16.0 landed