Proposal: Add JSON support
in [PgSql]
|
From: Petr Jelinek on 2 Apr 2010 00:34 Dne 1.4.2010 5:39, Joseph Adams napsal(a): > I ended up reinventing the wheel and writing another JSON library: > > http://constellationmedia.com/~funsite/static/json-0.0.1.tar.bz2 > > This is a first release, and it doesn't really have a name besides > "json". It's very similar to cJSON, except it is (sans unknown bugs) > more reliable, more correct, and cleaner (unless you hate gotos ;-) ). > It has a simple test suite. It is not prone to stack overflows, as > it doesn't recurse. It is strict, requires input to be UTF-8 (it > validates it first) and only outputs UTF-8. Other than treating > numbers liberally, my implementation only accepts valid JSON code (it > doesn't try to correct anything, even Unicode problems). It is under > the MIT license. > I did some testing on my own, it passed everything I have thrown at it so far. I also did tests using MSVC for both 32bit and 64bit targets and it worked fine too (except for missing stdbool.h in msvc which is no big deal). The coding style compared to cJSON (or other libs I've seen) seems closer to the style of PostgreSQL, it would however still require pgindent run and maybe some minor adjustments. -- Regards Petr Jelinek (PJMODOS) -- 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: "David E. Wheeler" on 2 Apr 2010 11:36 On Apr 1, 2010, at 9:34 PM, Petr Jelinek wrote: >> I ended up reinventing the wheel and writing another JSON library: >> >> http://constellationmedia.com/~funsite/static/json-0.0.1.tar.bz2 >> >> This is a first release, and it doesn't really have a name besides >> "json". It's very similar to cJSON, except it is (sans unknown bugs) >> more reliable, more correct, and cleaner (unless you hate gotos ;-) ). >> It has a simple test suite. It is not prone to stack overflows, as >> it doesn't recurse. It is strict, requires input to be UTF-8 (it >> validates it first) and only outputs UTF-8. Other than treating >> numbers liberally, my implementation only accepts valid JSON code (it >> doesn't try to correct anything, even Unicode problems). It is under >> the MIT license. >> > > I did some testing on my own, it passed everything I have thrown at it so far. > I also did tests using MSVC for both 32bit and 64bit targets and it worked fine too (except for missing stdbool.h in msvc which is no big deal). > > The coding style compared to cJSON (or other libs I've seen) seems closer to the style of PostgreSQL, it would however still require pgindent run and maybe some minor adjustments. Someone approve this project for the GSoC quick, before Joseph finishes it! Best, David -- 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: Joseph Adams on 3 Apr 2010 08:59 I've been wondering whether the JSON datatype should be strict or conservative. For one, there's strict JSON (following the exact specification). Then there's more conservative JSON variants. Some JSON parsers support comments, some support invalid number formats (e.g. '3.' or '+5'), etc.. The consensus seems to be that JSON content should be stored verbatim (it should store the exact string the client sent to it), as is done with XML. However, this notion is somewhat incompatible with "Be conservative in what you do; be liberal in what you accept from others" because we can't accept loose JSON, then spit out conservative JSON without messing with the content. Here's my idea: the datatype should only allow strict JSON, but there should be a function that accepts a liberal format, cleans it up to make it strict JSON, and converts it to JSON. I think making strict JSON the default makes the most sense because: * Inputs to the database will most likely be coming from programs, not humans. * Output is expected to be valid JSON and work anywhere JSON should work. * Strict JSON is what more people would expect, I'd think. -- 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: Mike Rylander on 3 Apr 2010 09:53 On Sat, Apr 3, 2010 at 8:59 AM, Joseph Adams <joeyadams3.14159(a)gmail.com> wrote: > I've been wondering whether the JSON datatype should be strict or conservative. > > For one, there's strict JSON (following the exact specification). > Then there's more conservative JSON variants. Some JSON parsers > support comments, some support invalid number formats (e.g. '3.' or > '+5'), etc.. > > The consensus seems to be that JSON content should be stored verbatim > (it should store the exact string the client sent to it), as is done > with XML. However, this notion is somewhat incompatible with "Be > conservative in what you do; be liberal in what you accept from > others" because we can't accept loose JSON, then spit out conservative > JSON without messing with the content. > > Here's my idea: the datatype should only allow strict JSON, but there > should be a function that accepts a liberal format, cleans it up to > make it strict JSON, and converts it to JSON. I think making strict > JSON the default makes the most sense because: > * Inputs to the database will most likely be coming from programs, not humans. > * Output is expected to be valid JSON and work anywhere JSON should work. > * Strict JSON is what more people would expect, I'd think. +1 -- Mike Rylander | VP, Research and Design | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: miker(a)esilibrary.com | web: http://www.esilibrary.com -- 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: Andrew Dunstan on 3 Apr 2010 11:20
Mike Rylander wrote: >> >> Here's my idea: the datatype should only allow strict JSON, but there >> should be a function that accepts a liberal format, cleans it up to >> make it strict JSON, and converts it to JSON. I think making strict >> JSON the default makes the most sense because: >> * Inputs to the database will most likely be coming from programs, not humans. >> * Output is expected to be valid JSON and work anywhere JSON should work. >> * Strict JSON is what more people would expect, I'd think. >> > > +1 > > Yeah. That's the only thing that makes sense to me. We don't allow badly formed XML, for example, although we do allow document fragments (as required by the standard, IIRC). But we could sensibly have some function like 'cleanup_json(almost_json text) returns json'. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |