From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Kouber Saparev <kouber(at)gmail(dot)com> |
Cc: | Vitaly Burovoy <vitaly(dot)burovoy(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #14354: Wrong interpretation of JSON 'null' |
Date: | 2016-10-06 12:47:16 |
Message-ID: | 28893.1475758036@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Kouber Saparev <kouber(at)gmail(dot)com> writes:
> Okay, I also saw in the source code that it is looking for an _json-object_
> (whatever that means) and is throwing that error otherwise. The thing is -
> in my perception the string 'null' , being valid json(b), should also be
> treated as valid _json-object_, isn't it?
No. A JSON "object" is something with field names and values, like a
Perl hash. JSON also has scalars and arrays; those are JSON values,
but not JSON objects. 'null' is a scalar, I think, although for some
purposes it might be better to view it as a fourth primitive kind of
JSON value.
jsonb_each_text() needs to work on a JSON object because otherwise its
return convention of returning a set of field names and values makes
no sense. What would you imagine jsonb_each_text('2'::jsonb) ought
to do? Similarly, there's not really any sensible interpretation
of jsonb_each_text('null'::jsonb).
> ... I felt its an
> inconsistency in PostgreSQL itself.
The distinction between objects and other kinds of JSON values is
drawn in the JSON standard; we did not make it up. See
http://rfc7159.net/rfc7159
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Vitaly Burovoy | 2016-10-06 12:50:55 | Re: BUG #14354: Wrong interpretation of JSON 'null' |
Previous Message | Marco Colombo | 2016-10-06 11:43:14 | Re: BUG #14351: Upsert not working in case of partitioned tables |