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

From Mike Rylander
Subject Re: Proposal: Add JSON support
Date
Msg-id v2xb918cf3d1004030653i6c71b473lb4eb8afba3d2386b@mail.gmail.com
Whole thread Raw
In response to Re: Proposal: Add JSON support  (Joseph Adams <joeyadams3.14159@gmail.com>)
Responses Re: Proposal: Add JSON support  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
On Sat, Apr 3, 2010 at 8:59 AM, Joseph Adams <joeyadams3.14159@gmail.com> wrote:
> I've been wondering whether the JSON datatype should be strict or conservative.
>
> For one, there's strict JSON (following the exact specification).
> Then there's more conservative JSON variants.  Some JSON parsers
> support comments, some support invalid number formats (e.g. '3.' or
> '+5'), etc..
>
> The consensus seems to be that JSON content should be stored verbatim
> (it should store the exact string the client sent to it), as is done
> with XML.  However, this notion is somewhat incompatible with "Be
> conservative in what you do; be liberal in what you accept from
> others" because we can't accept loose JSON, then spit out conservative
> JSON without messing with the content.
>
> Here's my idea: the datatype should only allow strict JSON, but there
> should be a function that accepts a liberal format, cleans it up to
> make it strict JSON, and converts it to JSON.  I think making strict
> JSON the default makes the most sense because:
>  * Inputs to the database will most likely be coming from programs, not humans.
>  * Output is expected to be valid JSON and work anywhere JSON should work.
>  * Strict JSON is what more people would expect, I'd think.

+1

--
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: Markus Wanner
Date:
Subject: Re: [RFC] nodeToString format and exporting the SQL parser
Next
From: Tom Lane
Date:
Subject: Re: message clarifications