Re: Proposal: Add JSON support - Mailing list pgsql-hackers

From Mike Rylander
Subject Re: Proposal: Add JSON support
Date
Msg-id t2rb918cf3d1004060753ja458c9fyfe1b960e10eeb369@mail.gmail.com
Whole thread Raw
In response to Re: Proposal: Add JSON support  (Joseph Adams <joeyadams3.14159@gmail.com>)
List pgsql-hackers
On Mon, Apr 5, 2010 at 11:50 PM, Joseph Adams
<joeyadams3.14159@gmail.com> wrote:
> Another JSON strictness issue:  the JSON standard (
> http://www.ietf.org/rfc/rfc4627.txt ) states that JSON text can only
> be an array or object.  However, my implementation currently accepts
> any valid value.  Thus, '3', '"hello"', 'true', 'false', and 'null'
> are all accepted by my implementation, but are not strictly JSON text.
>  The question is: should the JSON datatype accept atomic values (those
> that aren't arrays or objects) as valid JSON?
>
> I tried a few other JSON implementations to see where they stand
> regarding atomic types as input:
>
> JSON_checker (C) does not accept them.
> JSON.parse() (JavaScript) accepts them.
> json_decode() (PHP) accepts them.  However, support is currently buggy
> (e.g. '1' is accepted, but '1 ' is not).
> cJSON (C) accepts them.
> JSON.pm (Perl) accepts them if you specify the allow_nonref option.
> Otherwise, it accepts 'true' and 'false', but not 'null', a number, or
> a string by itself.
>
> In my opinion, we should accept an atomic value as valid JSON content.
>  I suppose we could get away with calling it a "content" fragment as
> is done with XML without a doctype.
>
> Accepting atomic values as valid JSON would be more orthagonal, as it
> would be possible to have a function like this:
>
> json_values(object_or_array JSON) RETURNS SETOF JSON
> -- extracts values from an object or members from an array, returning
> them as JSON fragments.
>

For these reasons, and the fact that my project uses atomic values ;),
I think yes, we should support them.

IIUC, the reason for requiring an array or object is that the O part
of JSON means "some sort of a collection of atomic values".  But, in
ECMAScript (JavaScript), instances of strings, numbers, bools and null
are, indeed, objects.  IOW, I think JSON is using a faulty definition
of "object" in the spec.  It's the one part of the spec that doesn't
make sense to me at all.

> Also, should we go even further and accept key:value pairs by themselves? :
>
> '"key":"value"'::JSON
>

This, though, is probably a step too far.   It violates the JS part of JSON ...

> I don't think we should because doing so would be rather zany.  It
> would mean JSON content could be invalid in value context, as in:
>
> // JavaScript
> var content = "key" : "value";
>

Right.

Thanks, Joseph.  I think this will be a great addition!

--
Mike Rylander| VP, Research and Design| Equinox Software, Inc. / The Evergreen Experts| phone:  1-877-OPEN-ILS
(673-6457)|email:  miker@esilibrary.com| web:  http://www.esilibrary.com 


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: pending patch: Re: Streaming replication and pg_xlogfile_name()
Next
From: Heikki Linnakangas
Date:
Subject: Re: recovery.conf.sample