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