Re: BUG #13936: jsonb_object() -> ERROR: unknown type of jsonb container
От | Andrew Dunstan |
---|---|
Тема | Re: BUG #13936: jsonb_object() -> ERROR: unknown type of jsonb container |
Дата | |
Msg-id | 56B9F9B5.9060409@dunslane.net обсуждение исходный текст |
Ответ на | Re: BUG #13936: jsonb_object() -> ERROR: unknown type of jsonb container (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: BUG #13936: jsonb_object() -> ERROR: unknown type of jsonb container
|
Список | pgsql-bugs |
On 02/09/2016 06:57 AM, Michael Paquier wrote: > On Tue, Feb 9, 2016 at 10:45 AM, Peter Geoghegan <pg@heroku.com> wrote: >> On Mon, Feb 8, 2016 at 11:52 AM, <xtracoder@gmail.com> wrote: >>> Here is the simple code to reproduce: >>> >>> select jsonb_object('{}'::text[], '{}'::text[]) >>> >>> Result of execution is >>> >>> ERROR: unknown type of jsonb container >>> ********** Error ********** >>> >>> ERROR: unknown type of jsonb container >>> SQL state: XX000 >>> >>> Expected result - jsonb object with no attributes, i.e.: '{}' >> I agree that this is a bug. >> >> Looks like it's coming from the jsonb output function, which is an >> additional concern: > Yep, this comes from a copy-paste error in jsonb_object_two_arg from > json_object_two_arg, caused by this bit particularly: > if (nkdims == 0) > PG_RETURN_DATUM(CStringGetTextDatum("{}")); > json is represented as an equivalent of a text data type, but that's > not the case of jsonb. So while this will work for json, that's really > broken for jsonb. Oh. Feeling a bit sheepish right now. > > One way to address this issue is to call jsonb_from_cstring() when > nkdims == 0. Another method, a bit more complex, is to build an empty > object and then return it as a result, like more or less that for > example: > pushJsonbValue(&result.parseState, WJB_BEGIN_OBJECT, NULL); > result = pushJsonbValue(&result.parseState, WJB_END_OBJECT, NULL); > return result; > > The patch attached uses jsonb_from_cstring(), with new regression > tests, and it fixes the issue for me. That seems more simple, but the > other method would work as well, though I am not sure this is worth > the complication. Yeah, I don't think we need to optimize this case too much. I'll get it done. cheers andrew
В списке pgsql-bugs по дате отправления: