Re: jsonb_concat: make sure we always return a non-scalar value

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Oskari Saarenmaa <os(at)ohmu(dot)fi>, Andrew Dunstan <andrew(at)dunslane(dot)net>, <pgsql-hackers(at)postgresql(dot)org>
Cc: Дмитрий Долгов <9erthalion6(at)gmail(dot)com>
Subject: Re: jsonb_concat: make sure we always return a non-scalar value
Date: 2015-09-09 22:20:22
Message-ID: 55F0B0A6.9030402@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 9/9/15 12:03 PM, Oskari Saarenmaa wrote:
>> andrew=# select '[1]'::jsonb || '{"a":"b"}';
>> ?column?
>> -----------------
>> [1, {"a": "b"}]
>
> It looks wrong, but I'm not sure what's right in that case. I think
> it'd make sense to just restrict concatenation to object || object,
> array || array and array || scalar and document that. I doubt many
> people expect their objects to turn into arrays if they accidentally
> concatenate an array into it. Alternatively the behavior could depend
> on the order of arguments for concatenation, array || anything -> array,
> object || array -> error.

That definitely doesn't sound like a good default.

It might be useful to have a concat function that would concatinate
anything into an array. But if we don't provide one by default users
could always create their own with json__typeof() and json_build_array().
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2015-09-09 22:26:46 Re: Modernizing contrib/tablefunc
Previous Message David Fetter 2015-09-09 22:03:02 Modernizing contrib/tablefunc