From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | matti(dot)hameister(at)technologygroup(dot)de |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #10728: json_to_recordset with nested json objects NULLs columns |
Date: | 2014-06-23 07:36:16 |
Message-ID: | CAB7nPqS0b=1DEKPWTQgzB0L3iV-ZQxTdffnqpc2Qp8_F1U2-6A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On Mon, Jun 23, 2014 at 2:13 PM, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
wrote:
> I am guessing that the bug origin is in pg_parse_json in the way nested
> json is managed, it is the only code path of populate_recordset_worker
> where a switch on JSON[B]OID is used.
>
Digging into that, I am seeing that the hash table used to find the field
values queried in populate_recordset_object_end in the hash table
(PopulateRecordsetState *)->json_hash has null entries for all the columns
inserted before the last nested json value. For example in my last example
with '[{"a":2,"b":3,"c":{"z":4}, "d":6}]', this results in having null
values for "a" and "b", "c" and "d" remaining correct.
populate_recordset_object_field_end inserts those values correctly within
the hash table though, so something strange is going on when inserting in
json_hash directly a json value.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Sebastien FLAESCH | 2014-06-23 08:15:06 | Re: BUG #10707: UPPER() does not convert non-ASCII chars |
Previous Message | digoal | 2014-06-23 07:17:59 | BUG #10734: PostgreSQL 9.3.4 shutdown forever in zfsonlinux 0.6.3-1 filesystem |
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2014-06-23 08:02:21 | Re: [Fwd: Re: proposal: new long psql parameter --on-error-stop] |
Previous Message | Kyotaro HORIGUCHI | 2014-06-23 07:14:21 | Re: How to change the pgsql source code and build it?? |