Proposal: Add JSON support
in [PgSql]
|
From: Josh Berkus on 30 Mar 2010 20:58 > I'd think that you could get quite a long ways on this, at least doing > something like dbslayer without *necessarily* needing to do terribly > much work inside the DB engine. There's actually an HTTP framework tool for Postgres which already does something of the sort. It was introduced at pgCon 2 years ago ... will look for. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.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: Robert Haas on 30 Mar 2010 21:03 On Tue, Mar 30, 2010 at 8:58 PM, Josh Berkus <josh(a)agliodbs.com> wrote: >> I'd think that you could get quite a long ways on this, at least doing >> something like dbslayer without *necessarily* needing to do terribly >> much work inside the DB engine. > > There's actually an HTTP framework tool for Postgres which already does > something of the sort. It was introduced at pgCon 2 years ago ... will > look for. While it might be interesting to have/find/write a tool that puts an HTTP/JSON layer around the DB connection, it's pretty much entirely unrelated to the proposed project of creating a json type with PostgreSQL analagous to the xml type we already have, which is what the OP is proposing to do. Personally, I suspect that a JSON type is both a more interesting project to work on and a more useful result for this community. ....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: Andrew Dunstan on 30 Mar 2010 21:56 Robert Haas wrote: > While it might be interesting to have/find/write a tool that puts an > HTTP/JSON layer around the DB connection, it's pretty much entirely > unrelated to the proposed project of creating a json type with > PostgreSQL analagous to the xml type we already have, which is what > the OP is proposing to do. > > Personally, I suspect that a JSON type is both a more interesting > project to work on and a more useful result for this community. > > > I agree. 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
From: Chris Browne on 31 Mar 2010 11:14 robertmhaas(a)gmail.com (Robert Haas) writes: > On Tue, Mar 30, 2010 at 8:58 PM, Josh Berkus <josh(a)agliodbs.com> wrote: >>> I'd think that you could get quite a long ways on this, at least doing >>> something like dbslayer without *necessarily* needing to do terribly >>> much work inside the DB engine. >> >> There's actually an HTTP framework tool for Postgres which already does >> something of the sort. �It was introduced at pgCon 2 years ago ... will >> look for. > > While it might be interesting to have/find/write a tool that puts an > HTTP/JSON layer around the DB connection, it's pretty much entirely > unrelated to the proposed project of creating a json type with > PostgreSQL analagous to the xml type we already have, which is what > the OP is proposing to do. > > Personally, I suspect that a JSON type is both a more interesting > project to work on and a more useful result for this community. No disagreement here; I'd expect that a JSON type would significantly ease building such a framework. Indeed, that could be a demonstration of success... "We then implemented an HTTP/JSON proxy in 27 lines of Python code..." :-) -- "Unless you used NetInfo. _Then_ changing network settings could often require torching of the existing system, salting of the ground it had rested on, and termination of anyone who used it." -- JFW <jwiede(a)biff.com> on comp.sys.next.advocacy
From: Joseph Adams on 31 Mar 2010 23:39
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. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |