Re: Proposal: Add JSON support

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Petr Jelinek <pjmodos(at)pjmodos(dot)net>
Cc: 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 16:03:12
Message-ID: 21867.1270569792@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Petr Jelinek <pjmodos(at)pjmodos(dot)net> writes:
> Dne 6.4.2010 7:57, Joseph Adams napsal(a):
>> To me, the most logical approach is to do the obvious thing: make
>> JSON's 'null' be SQL's NULL. For instance, SELECTing on a table with
>> NULLs in it and converting the result set to JSON would yield a
>> structure with 'null's in it. 'null'::JSON would yield NULL. I'm not
>> sure what startling results would come of this approach, but I'm
>> guessing this would be most intuitive and useful.

> +1

I think it's a pretty bad idea for 'null'::JSON to yield NULL. AFAIR
there is no other standard datatype for which the input converter can
yield NULL from a non-null input string, and I'm not even sure that the
InputFunctionCall protocol allows it. (In fact a quick look indicates
that it doesn't...)

To me, what this throws into question is not so much whether JSON null
should equate to SQL NULL (it should), but whether it's sane to accept
atomic values. If I understood the beginning of this discussion, that's
not strictly legal. I think it would be better for strict input mode
to reject this, and permissive mode to convert it to a non-atomic value.
Thus jsonify('null') wouldn't yield NULL but a structure containing a
null.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-04-06 16:07:08 Re: Remaining Streaming Replication Open Items
Previous Message David E. Wheeler 2010-04-06 15:58:39 Re: Prepared query parsing much slower in 9.0?