On Tue, Apr 6, 2010 at 2:20 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
I'm not sure what the other option is. If you do SELECT col FROM
table, I'm not aware that you can return differently-typed values for
different rows...
> 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.)
Yes, that seems like a useful support function.
...Robert
