Jim Nasby <jim.na...@bluetreble.com> writes:
> On 5/22/15 2:44 PM, Andrew Dunstan wrote:
>> 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.
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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
