<br /><br /><div class="gmail_quote">On Tue, May 1, 2012 at 9:56 AM, Joey Adams <span dir="ltr"><<a
href="mailto:joeyadams3.14159@gmail.com"target="_blank">joeyadams3.14159@gmail.com</a>></span> wrote:<br
/><blockquoteclass="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div
class="im">OnTue, May 1, 2012 at 12:22 PM, Andrew Dunstan <<a
href="mailto:andrew@dunslane.net">andrew@dunslane.net</a>>wrote:<br /> > Second, RFC 4627 is absolutely clear: a
validJSON value can only be an<br /> > object or an array, so this thing about converting arbitrary datum values
to<br/> > JSON is a fantasy. If anything, we should adjust the JSON input routines to<br /> > disallow anything
else,rather than start to output what is not valid JSON.<br /><br /></div>No, the RFC says (emphasis mine):<br /><br />
A JSON *text* is a serialized object or array.<br /><br /> If we let the JSON type correspond to a *value* instead,
this<br/> restriction does not apply, and the JSON type has a useful recursive<br /> definition.<br /><br /> For
example,this function would not be possible if we applied the<br /> "object or array" restriction:<br /><br />
unnest(json)returns setof json<br /><br /> Note that a similar distinction appears with the XML type: "document"<br />
versus"content".<br /><span class="HOEnZb"><font color="#888888"><br /><br /></font></span></blockquote></div><br />I
thinkyou're playing with words. But in any case, the RFC says this regarding generators:<br /><br /><pre>5. Generators
A JSON generator produces JSON text. The resulting text MUST strictly conform to the JSON grammar.<br /><br />Our
functionsdo seem to be JSON generators. So even if we accept things that aren't JSON texts in our parser (possibly
permittedby section 4 of the RFC) we should not be generating them.<br />
<br /><br />cheers<br /><br />andrew<br /><br /></pre><br />