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

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