Re: jsonb concatenate operator's semantics seem questionable

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Peter Geoghegan <pg(at)heroku(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Josh Berkus <josh(at)agliodbs(dot)com>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, Marko Tiikkaja <marko(at)joh(dot)to>, Ryan Pedela <rpedela(at)datalanche(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Ilya Ashchepkov <koctep(at)gmail(dot)com>
Subject: Re: jsonb concatenate operator's semantics seem questionable
Date: 2015-05-22 22:46:38
Message-ID: 555FB1CE.7080409@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 5/22/15 4:54 PM, Tom Lane wrote:
> Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)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.

I think the validation case would be if you're doing transforms or other
things to the JSON in SQL, to make sure it's matching what you're
expecting it to. For example, if you have something in json that
actually has duplicated keys, if you simply cast that to jsonb then all
but one of the dupes is silently dropped. I don't like just assuming
that's OK. There's probably other cases like this.

That said, I don't think users have pushed our JSON stuff enough yet to
do more than guess at these use cases. Presumably it will be easier to
tell if this is a problem as people start using the more advanced
operators and functions.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2015-05-22 22:57:20 Re: jsonb concatenate operator's semantics seem questionable
Previous Message Josh Berkus 2015-05-22 22:45:22 Re: Change pg_cancel_*() to ignore current backend