Re: [HACKERS] BUG #10728: json_to_recordset with nested json objects NULLs columns

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, matti(dot)hameister(at)technologygroup(dot)de, pgsql-bugs(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] BUG #10728: json_to_recordset with nested json objects NULLs columns
Date: 2014-06-24 00:34:08
Message-ID: 53A8C780.2070701@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers


On 06/23/2014 07:34 PM, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> On 06/23/2014 11:43 AM, Tom Lane wrote:
>>> However, it seems to me that these functions (json[b]_to_record[set]) are
>>> handling the nested-json-objects case in a fairly brain-dead fashion to
>>> start with. I would like to propose that we should think about getting
>>> rid of the use_json_as_text flag arguments altogether. What purpose do
>>> they serve? If we're going to the trouble of parsing the nested JSON
>>> objects anyway, why don't we just reconstruct from that data?
>> Looks like we have some problems in this whole area, not just the new
>> function, so we need to fix 9.3 also :-(
>> IIRC, originally, the intention was to disallow nested json objects, but
>> the use_json_as_text was put in as a possibly less drastic possibility.
>> If we get rid of it our only recourse is to error out if we encounter
>> nested json. I was probably remiss in not considering the likelihood of
>> a json target field.
>> I currently don't have lots of time to devote to this, sadly, but
>> Michael's patch looks like a good minimal fix.
> I can spend some time on it over the next couple of days. I take it you
> don't have a problem with the concept of doing recursive processing,
> as long as it doesn't add much complication?
>
> I'm not following your comment about 9.3. The json[b]_to_record[set]
> functions are new in 9.4, which is what makes me feel it's not too
> late to redefine their behavior. But changing behavior of stuff that
> was in 9.3 seems a lot more debatable.
>
>

This problem is also manifest in json_populate_recordset, which also
uses the function in question, and is in 9.3:

andrew=# create type yyy as (a int, b json, c int, d int);
CREATE TYPE
andrew=# select * from json_populate_recordset(null::yyy, '[
{"a":2,"c":3,"b":{"z":4}, "d":6}
]
',true) x;
a | b | c | d
---+---------+---+---
| {"z":4} | | 6
(1 row)

I don't have any problem with recursive processing, but I'm not sure I
understand how it will work. If you post a patch I will be able to look
it over, though.

cheers

andrew

>

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2014-06-24 01:43:31 Re: [HACKERS] BUG #10728: json_to_recordset with nested json objects NULLs columns
Previous Message Tom Lane 2014-06-23 23:34:08 Re: [BUGS] BUG #10728: json_to_recordset with nested json objects NULLs columns

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2014-06-24 01:06:57 Re: ALTER TABLESPACE MOVE command tag tweak
Previous Message Tom Lane 2014-06-23 23:34:08 Re: [BUGS] BUG #10728: json_to_recordset with nested json objects NULLs columns