| 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: | Whole Thread | Raw Message | 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
| 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 |