Thread: BUG #13936: jsonb_object() -> ERROR: unknown type of jsonb container
The following bug has been logged on the website:
Bug reference: 13936
Logged by: Xtra Coder
Email address: xtracoder@gmail.com
PostgreSQL version: 9.5.0
Operating system: Windows7
Description:
I'm getting absolutely misleading error message when trying to build a JSON
object from empty resultset.
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.: '{}'
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:
#0 errfinish (dummy=dummy@entry=0) at elog.c:412
#1 0x00000000007fc11d in elog_finish (elevel=elevel@entry=20,
fmt=fmt@entry=0x9c5c30 "unkno"...) at elog.c:1372
#2 0x000000000076b006 in iteratorFromContainer
(container=container@entry=0x1be0d2c, parent=parent@entry=0x0) at
jsonb_util.c:930
#3 0x000000000076c3b4 in JsonbIteratorInit
(container=container@entry=0x1be0d2c) at jsonb_util.c:719
#4 0x0000000000766ea1 in JsonbToCStringWorker (out=0x1c74780,
out@entry=0x0, in=0x1be0d2c, estimated_len=6, indent=indent@entry=0
'\000') at jsonb.c:471
#5 0x000000000076855c in JsonbToCString (out=out@entry=0x0,
in=<optimized out>, estimated_len=<optimized out>) at jsonb.c:430
#6 0x000000000076857e in jsonb_out (fcinfo=<optimized out>) at jsonb.c:136
#7 0x00000000007fec03 in FunctionCall1Coll
(flinfo=flinfo@entry=0x1c6d0f0, collation=collation@entry=0,
arg1=arg1@entry=29232424) at fmgr.c:1297
#8 0x000000000080015f in OutputFunctionCall (flinfo=0x1c6d0f0,
val=29232424) at fmgr.c:1950
#9 0x000000000047294d in (slot=0x1c6c650, self=0x1be13c0) at printtup.c:359
--
Peter Geoghegan
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.
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.
Regards,
--
Michael
Attachment
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
On Tue, Feb 9, 2016 at 11:37 PM, Andrew Dunstan <andrew@dunslane.net> wrote: > On 02/09/2016 06:57 AM, Michael Paquier wrote: >> 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. OK, good to know. Feel free to ping me if you need some extra hands, though I don't think you will actually need them :) > I'll get it done. Thanks. -- Michael
On Wed, Feb 10, 2016 at 9:07 AM, Michael Paquier <michael.paquier@gmail.com> wrote: > On Tue, Feb 9, 2016 at 11:37 PM, Andrew Dunstan <andrew@dunslane.net> wrote: >> On 02/09/2016 06:57 AM, Michael Paquier wrote: >>> 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. > > OK, good to know. Feel free to ping me if you need some extra hands, > though I don't think you will actually need them :) Entry in next CF to not get that lost is here: https://commitfest.postgresql.org/9/515/ -- Michael
On 02/09/2016 06:57 AM, Michael Paquier wrote:
>
> 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.
>
> 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.
> Regards,
I have committed a fix for this, mainly using your patch. In the end I
used the same pattern for handling the case that we use in the
one-argument form of the function, i.e. we just drop through to the end,
skipping over the part where we add object elements.
cheers
andrew
On Mon, Feb 22, 2016 at 12:46 AM, Andrew Dunstan <andrew@dunslane.net> wrote: > I have committed a fix for this, mainly using your patch. In the end I used > the same pattern for handling the case that we use in the one-argument form > of the function, i.e. we just drop through to the end, skipping over the > part where we add object elements. Thanks. I have hesitated with your solution, looks like I was on the wrong side at the end :) -- Michael