On 5/22/15 2:44 PM, Andrew Dunstan wrote:
>
> On 05/22/2015 03:27 PM, Peter Geoghegan wrote:
>> On Fri, May 22, 2015 at 11:59 AM, Andrew Dunstan <andrew@dunslane.net>
>> wrote:
>>> As for raising an error, in principle it's doable, but the code to
>>> detect it
>>> might get messy. Also, I don't want a huge number of knobs. So I'm
>>> excited
>>> about the idea.
>> I think that that's a bad default behavior, although I don't think
>> that's what Jim means. Consider our experience with having subscript
>> operators throw errors -- it complicates certain cases (my complaint
>> at the time was about expression indexes, but there are others).
>>
>
>
> I certainly agree about indexable operations. However this seems
> unlikely to be indexed, although I'm prepared to be educated on that point.
>
> Still I'd rather not add yet another parameter to the function, and I
> certainly don't want to make throwing an error the only behaviour.
If instead of a create_missing boolean it accepted an enum we could
handle both (since they're related). But I'd also like to avoid Yet More
Knobs if possible.
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.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com