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 <and...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
