Proposal: Add JSON support
in [PgSql]
|
From: Alvaro Herrera on 6 Apr 2010 11:05 Joseph Adams escribi�: > http://constellationmedia.com/~funsite/static/json-0.0.2.tar.bz2 > > My json.c is now 1161 lines long, so I can't quite call it "small" anymore. Just noticed you don't check the return value of malloc and friends. How do you intend to handle that? There are various places that would simply dump core with the 0.0.2 code. Within Postgres it's easy -- a failed palloc aborts the transaction and doesn't continue running your code. But in a standalone library that's probably not acceptable. If we were to import this there are some lines that could be ripped out, like 60 lines in the string buffer stuff and 130 lines for Unicode. That brings your code just under 1000 lines. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 6 Apr 2010 12:03 Petr Jelinek <pjmodos(a)pjmodos.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 6 Apr 2010 13:04 On Tue, Apr 6, 2010 at 11:05 AM, Alvaro Herrera <alvherre(a)commandprompt.com> wrote: > Joseph Adams escribió: > >> http://constellationmedia.com/~funsite/static/json-0.0.2.tar.bz2 >> >> My json.c is now 1161 lines long, so I can't quite call it "small" anymore. > > Just noticed you don't check the return value of malloc and friends. > How do you intend to handle that? There are various places that would > simply dump core with the 0.0.2 code. Within Postgres it's easy -- a > failed palloc aborts the transaction and doesn't continue running your > code. But in a standalone library that's probably not acceptable. > > If we were to import this there are some lines that could be ripped out, > like 60 lines in the string buffer stuff and 130 lines for Unicode. > That brings your code just under 1000 lines. Let me be the first to suggest putting this code under the PostgreSQL license. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 6 Apr 2010 13:28 On Tue, Apr 6, 2010 at 12:03 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Petr Jelinek <pjmodos(a)pjmodos.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...) Oh. I missed this aspect of the proposal. I agree - that's a bad idea. > 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. With this, I disagree. I see no reason to suppose that a JSON NULL and an SQL NULL are the same thing. > 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. There's no obvious "structure" to convert this into. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 6 Apr 2010 13:31
Robert Haas <robertmhaas(a)gmail.com> writes: > On Tue, Apr 6, 2010 at 12:03 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> 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. > With this, I disagree. I see no reason to suppose that a JSON NULL > and an SQL NULL are the same thing. Oh. If they're not the same, then the problem is easily dodged, but then what *is* a JSON null? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |