Re: data to json enhancements

On 09/26/2012 06:46 PM, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> Drawing together various discussions both here and elsewhere (e.g. the
>> PostgresOpen hallway track) I propose to work on the following:
>> 1. make datum_to_json() honor a type's cast to json if it exists. The
>> fallback is to use the type's string representation, as now.
>> 2. add a cast hstore -> json (any others needed for core / contrib types ?)
>> 3. add a to_json(anyelement) function
>> 4. add a new aggregate function json_agg(anyrecord) -> json to simplify
>> and make more effecient turning a resultset into json.
>> Comments welcome.
> ISTM the notion of to_json(anyelement) was already heavily discussed and
> had spec-compliance issues ... in fact, weren't you one of the people
> complaining?  What exactly does #3 mean that is different from the
> previous thread?
>
> Also, on reflection I'm not sure about commandeering cast-to-json for
> this --- aren't we really casting to "json member" or something like
> that?  The distinction between a container and its contents seems
> important here.  With a container type as source, it might be important
> to do something different if we're coercing it to a complete JSON
> value versus something that will be just one member.  I'm handwaving
> here because I don't feel like going back to re-read the RFC, but
> it seems like something that should be considered carefully before
> we lock down an assumption that there can never be a difference.
"json value" is a superset of "json object", so no special handling
should be required here - they nest cleanly.

(you can check http://www.json.org/ for definition.)

I agree that one of the standards did say that "JSON generators"
should produce only JSON-serialised arrays and dictionaries and
not "JSON values" - that is one of (literal null, true or false or a 
json array, dictionary,
number or double-quoted string)

But if we would do that we would really be the _only_ one who would
place this restriction on their to_json function.

As I already reported in the previous discussion, neither python, ruby or
neither of the two javascripts I tested (mozilla & chrome) place this
restriction on their json serialisation functions.

Maybe the "JSON generator" in the standard means something else, like
a stand-alone program or server.

The only mention/definition for Generator in the RFC is

"5. Generators

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

To be formally standards compliant I propose that we officially define our
json type to store "a json value" and as json object is really just a 
subset of
json value we can provide (or just advise the use of)
a domain json_object, which has CHECK for the first non-whitespace char
being { or [ .

>             regards, tom lane
>
>