On Tue, Apr 6, 2010 at 2:20 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Tue, Apr 6, 2010 at 1:31 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
