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.
>> >This patch has a status "work in progress" of course. Generally
>> >speaking, this implementation extends the `ArrayRef` usage for the jsonb.
>> >And I need some sort of advice about several questions:
>> >
>> >* is it interesting for the community?
>> >* is that a good idea to extend the `ArrayRef` for jsonb? If it's
>> >appropriate, probably we can rename it to `ArrayJsonbRef` of something.
>> >* what can be improved in the code at the top level (function placement,
>> >probably, functionality duplication, etc.)?
>> >* are there any special cases, that I should take care of in this
>> >implementation?
> array/key ambiguity is going to be painful.
JSON keys are required to be strings, so maybe it's OK to differentiate
based on whether the index is a string or a number. Or perhaps we use
different nomenclature (ie: {} for objects).
We should also think about what would work for hstore. Adding this for
hstore is clearly separate work, but it'd be bad to close that door here.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Data in Trouble? Get it in Treble! http://BlueTreble.com
