Skip site navigation (1) Skip section navigation (2)

Re: JSON in 9.2 - Could we have just one to_json() function instead of two separate versions ?

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Joey Adams <joeyadams3(dot)14159(at)gmail(dot)com>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, Hannu Krosing <hannu(at)2ndquadrant(dot)com>, PavelStehule <pavel(dot)stehule(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: JSON in 9.2 - Could we have just one to_json() function instead of two separate versions ?
Date: 2012-05-01 18:11:52
Message-ID: CAD5tBcL2AqHjOu5ODPKjfhG+3_BHCyeTDGBov9xFHa97eEZ7sg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, May 1, 2012 at 9:56 AM, Joey Adams <joeyadams3(dot)14159(at)gmail(dot)com>wrote:

> On Tue, May 1, 2012 at 12:22 PM, Andrew Dunstan <andrew(at)dunslane(dot)net>
> wrote:
> > Second, RFC 4627 is absolutely clear: a valid JSON value can only be an
> > object or an array, so this thing about converting arbitrary datum
> values to
> > JSON is a fantasy. If anything, we should adjust the JSON input routines
> to
> > disallow anything else, rather than start to output what is not valid
> JSON.
>
> No, the RFC says (emphasis mine):
>
>    A JSON *text* is a serialized object or array.
>
> If we let the JSON type correspond to a *value* instead, this
> restriction does not apply, and the JSON type has a useful recursive
> definition.
>
> For example, this function would not be possible if we applied the
> "object or array" restriction:
>
>    unnest(json) returns setof json
>
> Note that a similar distinction appears with the XML type: "document"
> versus "content".
>
>
>
I think you're playing with words. But in any case, the RFC says this
regarding generators:

5. Generators

   A JSON generator produces JSON text.  The resulting text MUST
   strictly conform to the JSON grammar.

Our functions do seem to be JSON generators. So even if we accept
things that aren't JSON texts in our parser (possibly permitted by
section 4 of the RFC) we should not be generating them.


cheers

andrew

In response to

Responses

pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2012-05-01 18:15:08
Subject: Re: Problem with multi-job pg_restore
Previous:From: Brian WeaverDate: 2012-05-01 18:09:37
Subject: Re: Problem with multi-job pg_restore

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group