Re: Proposal: Add JSON support

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Petr Jelinek <pjmodos(at)pjmodos(dot)net>, Joseph Adams <joeyadams3(dot)14159(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: Add JSON support
Date: 2010-04-06 18:20:37
Message-ID: 24454.1270578037@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Apr 6, 2010 at 1:31 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-04-06 18:23:17 Re: Proposal: Add JSON support
Previous Message Tom Lane 2010-04-06 18:15:14 Re: SELECT constant; takes 15x longer on 9.0?