BUG #13936: jsonb_object() -> ERROR: unknown type of jsonb container

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

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

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

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

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

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

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

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

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

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

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

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

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs