From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | johann(at)visagie(dot)za(dot)net |
Cc: | pgsql-bugs(at)postgresql(dot)org, Andrew Dunstan <andrew(at)dunslane(dot)net> |
Subject: | Re: BUG #13996: json_to_record() returns non-NULL, malformed value for omitted key under some circumstances |
Date: | 2016-03-03 01:04:59 |
Message-ID: | 26373.1456967099@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
johann(at)visagie(dot)za(dot)net writes:
> SELECT t.*
> FROM json_to_record('{"a":1, "b":{"c":16, "d":2}, "x":8}'::json)
> AS t(a int, b json, c text, x int);
> However, if (as in this example) another key in the JSON object - `b` in
> this case - refers to a nested JSON object which *does* contain a key `c`,
> the function returns a malformed JSON string as (text) value for column
> `c`:
> a | b | c | x
> ---+----------------+---------+---
> 1 | {"c":16,"d":2} | {"c":16 | 8
> (1 row)
AFAICT this is a simple thinko in the hash_object_field_end() callback,
as per attached patch that fixes this and doesn't break any existing
regression test cases. Andrew, do you concur that this is correct,
or is there something I'm missing about the tracking of lex_level?
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
fix-nested-objects-in-json-to-record.patch | text/x-diff | 482 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2016-03-03 03:00:28 | Re: BUG #13996: json_to_record() returns non-NULL, malformed value for omitted key under some circumstances |
Previous Message | Michael Paquier | 2016-03-03 00:26:40 | Re: BUG #13770: Extending recovery_min_apply_delay on Standby causes it to be unavailable for a while |