On 08/20/2015 03:24 PM, Jim Nasby wrote:
> On 8/17/15 4:25 PM, Josh Berkus wrote:
>> On 08/17/2015 02:18 PM, Jim Nasby wrote:
>>> >On 8/17/15 3:33 PM, Josh Berkus wrote:
>>>> >>Again, how do we handle missing keys? Just return NULL? or
>>>> ERROR? I'd
>>>> >>prefer the former, but there will be arguments the other way.
>>> >
>>> >I've been wondering if we should add some kind of "strict" JSON. My
>>> big
>>> >concern is throwing an error if you try to provide duplicate keys, but
>>> >it seems reasonable that json_strict would throw an error if you
>>> try to
>>> >reference something that doesn't exist.
>> Only if there's demand for it. Is there?
>
> I'm certainly worried (paranoid?) about it. Postgres is very good
> about not silently dropping data and this seems a glaring departure
> from that. I haven't looked yet but I'm hoping this could at least be
> added as an extension without duplicating a bunch of the existing JSON
> stuff.
What on earth does this have to do with duplicate keys? The jsonb input
rules on duplicate keys are very clear, incidentally, and follow the
practice of most JSON processors (duplicates are discarded, last one
wins.) But that has nothing at all to do with this feature, really.
This feature can NOT be added as an extension, since it requires grammar
processing modification.
cheers
andrew
