On Fri, May 22, 2015 at 2:54 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I think there's essentially two scenarios for JSON usage; one where you
>> want to be pretty paranoid about things like keys aren't missing, you're
>> not trying to access a path that doesn't exist, etc. The other mode
>> (what we have today) is when you really don't care much about that stuff
>> and want the database to JustStoreIt. I don't know how many people would
>> want the stricter mode, but it certainly seems painful to try and
>> enforce that stuff today if you care about it.
>
> ISTM that the use case for JSON is pretty much JustStoreIt. If you had
> strict structural expectations you'd probably have chosen a more
> relational representation in the first place ... or else XML, which at
> least has heard of schemas and validation. So I definitely agree that
> we need the no-error case, and am not that excited about having an
> error-throwing variant.
I agree. The basic idea of JSON is that the schema is implicit. This
gives applications flexibility (but typically they require just a
little flexibility, and understand that JSON documents are still
fairly homogeneously structured).
Anyone that doesn't like that can just not use the JSON types, or can
use a check constraint with the JSON types.
--
Peter Geoghegan