Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Apr 6, 2010 at 1:31 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Oh. �If they're not the same, then the problem is easily dodged, but
>> then what *is* a JSON null?
> I assume we're going to treat JSON much like XML: basically text, but
> with some validation (and perhaps canonicalization) under the hood.
> So a JSON null will be "null", just a JSON boolean true value will be
> "true". It would be pretty weird if storing "true" or "false" or "4"
> or "[3,1,4,1,5,9]" into a json column and then reading it back
> returned the input string; but at the same time storing "null" into
> the column returned a SQL NULL.
Hmm. So the idea is that all JSON atomic values are considered to be
text strings, even when they look like something else (like bools or
numbers)? That would simplify matters I guess, but I'm not sure about
the usability. In particular I'd want to have something that dequotes
the value so that I can get foo not "foo" when converting to SQL text.
(I'm assuming that quotes would be there normally, so as not to lose
the distinction between 3 and "3" in the JSON representation.)
regards, tom lane
