Re: jsonb concatenate operator's semantics seem questionable

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: jsonb concatenate operator's semantics seem questionable
Дата
Msg-id 555FB1CE.7080409@BlueTreble.com
обсуждение исходный текст
Ответ на Re: jsonb concatenate operator's semantics seem questionable  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 5/22/15 4:54 PM, Tom Lane wrote:
> Jim Nasby <Jim.Nasby@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.

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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: Change pg_cancel_*() to ignore current backend
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: jsonb concatenate operator's semantics seem questionable