Re: [HACKERS] SQL/JSON in PostgreSQL - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] SQL/JSON in PostgreSQL
Date
Msg-id CA+Tgmobmf4gZcFG8b9hz=ebxsUX=b-z=t0D904C+-zRaJT_BCg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] SQL/JSON in PostgreSQL  ("Sven R. Kunze" <srkunze@mail.de>)
Responses Re: [HACKERS] SQL/JSON in PostgreSQL  ("Sven R. Kunze" <srkunze@mail.de>)
Re: [HACKERS] SQL/JSON in PostgreSQL  (Nico Williams <nico@cryptonector.com>)
List pgsql-hackers
On Thu, Mar 9, 2017 at 12:48 PM, Sven R. Kunze <srkunze@mail.de> wrote:
> On 08.03.2017 20:48, Peter van Hardenberg wrote:
>>
>> Small point of order: YAML is not strictly a super-set of JSON.
>
> I haven't read the whole standard, but from what I can see the standard
> considers JSON an official subset of itself:
> http://www.yaml.org/spec/1.2/spec.html

But there's apparent sophistry, like this, in that spec:

SON's RFC4627 requires that mappings keys merely “SHOULD” be unique,
while YAML insists they “MUST” be. Technically, YAML therefore
complies with the JSON spec, choosing to treat duplicates as an error.
In practice, since JSON is silent on the semantics of such duplicates,
the only portable JSON files are those with unique keys, which are
therefore valid YAML files.

I don't see how YAML can impose a stronger requirement than JSON and
yet claim to be a superset; a JSON document that doesn't meet that
requirement will be legal (if stupid) as JSON but illegal as YAML.

Also, even if the superset thing were true on a theoretical plane, I'm
not sure it would do us much good in practice.  If we start using
YAML-specific constructs, we won't have valid JSON any more.  If we
use only things that are legal in JSON, YAML's irrelevant.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] use SQL standard error code for nextval
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] [PATCH] Enabling atomics on ARM64