Re: jsonb_concat: make sure we always return a non-scalar value
От
Andrew Dunstan
Тема
Re: jsonb_concat: make sure we always return a non-scalar
value
Дата
Msg-id
55EEE89D.1060202@dunslane.net
Ответ на
jsonb_concat: make sure we always return a non-scalar value (Oskari Saarenmaa)
Список
Дерево обсуждения
jsonb_concat: make sure we always return a non-scalar value Oskari Saarenmaa <os@ohmu.fi>
Re: jsonb_concat: make sure we always return a non-scalar
value Andrew Dunstan <andrew@dunslane.net>
Re: jsonb_concat: make sure we always return a
non-scalar value Teodor Sigaev <teodor@sigaev.ru>
Re: jsonb_concat: make sure we always return a non-scalar
value Andrew Dunstan <andrew@dunslane.net>
Re: jsonb_concat: make sure we always return a non-scalar value Thom Brown <thom@linux.com>
Re: jsonb_concat: make sure we always return a non-scalar
value Andrew Dunstan <andrew@dunslane.net>
Re: jsonb_concat: make sure we always return a non-scalar
value Oskari Saarenmaa <os@ohmu.fi>
Re: jsonb_concat: make sure we always return a non-scalar
value Jim Nasby <Jim.Nasby@BlueTreble.com>
Re: jsonb_concat: make sure we always return a non-scalar
value Andrew Dunstan <andrew@dunslane.net>
On 09/05/2015 02:47 AM, Oskari Saarenmaa wrote:
> There was a long thread about concatenating jsonb objects to each
> other, but that discussion didn't touch concatenating other types.
> Currently jsonb_concat always just returns the other argument if one
> of arguments is considered empty. This causes surprising behavior
> when concatenating scalar values to empty arrays:
>
> os=# select '[]'::jsonb || '1'::jsonb;
> 1
>
> os=# select '[]'::jsonb || '[1]'::jsonb;
> [1]
>
> os=# select '[]'::jsonb || '1'::jsonb || '2'::jsonb;
> [1, 2]
>
> os=# select '0'::jsonb || '1'::jsonb;
> [0, 1]
>
> os=# select '{"x": "y"}'::jsonb || '[1]'::jsonb;
> [{"x": "y"}, 1]
>
> os=# select '{"x": "y"}'::jsonb || '1'::jsonb;
> ERROR: invalid concatenation of jsonb objects
>
> Attached a patch to fix and test this. Also added a test case for
> concatenating two scalar values which currently produces an array..
> I'm not sure that behavior makes sense, but didn't want to change that
> in this patch as I guess someone could consider that feature useful.
This looks correct. Barring objection I'll apply this shortly.
cheers
andrew
В списке pgsql-hackers по дате отправления