Proposal: Add JSON support
in [PgSql]
|
From: "David E. Wheeler" on 29 Mar 2010 14:23 On Mar 29, 2010, at 9:02 AM, Tom Lane wrote: > If this is going to end up being one fairly small C file implementing > a spec that is not a moving target, I'd vote against depending on an > external library instead, no matter how spiffy and license-compatible > the external library might be. Perhaps you could fork one, in that case. 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 29 Mar 2010 14:33 On Mon, Mar 29, 2010 at 2:23 PM, David E. Wheeler <david(a)kineticode.com> wrote: > On Mar 29, 2010, at 9:02 AM, Tom Lane wrote: > >> If this is going to end up being one fairly small C file implementing >> a spec that is not a moving target, I'd vote against depending on an >> external library instead, no matter how spiffy and license-compatible >> the external library might be. > > Perhaps you could fork one, in that case. > > Best, > > David > > I'm considering using and adapting cJSON instead of continuing with my redundant implementation. I could run `indent -kr -i4` on it (will that match PostgreSQL's coding style?), add support for UTF-16 surrogate pairs (pair of \u... escapes for each character above U+FFFF as required by the JSON spec), and add a switch to turn on/off pure ASCII output. P.S.: Sorry for the repeat, David. I forgot to CC the mailing list. -- 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: Dimitri Fontaine on 29 Mar 2010 15:49 Tom Lane <tgl(a)sss.pgh.pa.us> writes: > If this is going to end up being one fairly small C file implementing > a spec that is not a moving target, I'd vote against depending on an > external library instead, no matter how spiffy and license-compatible > the external library might be. My understanding is that it's possible to include (fork) a MIT or BSD source code into our source tree, right? (Some other licenses certainly apply too). Regards, -- dim -- 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 29 Mar 2010 16:12 Dimitri Fontaine <dfontaine(a)hi-media.com> writes: > Tom Lane <tgl(a)sss.pgh.pa.us> writes: >> If this is going to end up being one fairly small C file implementing >> a spec that is not a moving target, I'd vote against depending on an >> external library instead, no matter how spiffy and license-compatible >> the external library might be. > My understanding is that it's possible to include (fork) a MIT or BSD > source code into our source tree, right? (Some other licenses certainly > apply too). MIT or 2-clause BSD would be ok for such a thing, other licenses probably not. 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: Chris Browne on 30 Mar 2010 17:38
joeyadams3.14159(a)gmail.com (Joseph Adams) writes: > I introduced myself in the thread "Proposal: access control jails (and > introduction as aspiring GSoC student)", and we discussed jails and > session-local variables. But, as Robert Haas suggested, implementing > variable support in the backend would probably be way too ambitious a > project for a newbie like me. I decided instead to pursue the task of > adding JSON support to PostgreSQL, hence the new thread. Interesting... I had a discussion about much this sort of thing with a local LUG associate; he was interested in this from a "doing CouchDB-ish things using PostgreSQL" perspective. There were a couple perspectives there, which may be somewhat orthogonal to what you're trying to do. I'll mention them as they may suggest useful operations. 1. Buddy Myles pointed out a NYTimes project which does something pretty analagous... http://code.nytimes.com/projects/dbslayer This is a proxy that allows clients to submit requests via HTTP, returning responses in JSON form. Note that the HTTP request has the SQL query embedded into it. 2. CouchDB's interface is much the same, where clients submit HTTP requests and receive JSON responses back, but with the difference that the query is a stylized sorta-JSON form. 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. Mapping a tuple, or a list of tuples, into a forest of JSON documents should be pretty straightforward; whether or not it's really desirable to operate a JSON-flavoured query inside PostgreSQL may be the difference between *this year's* GSOC and *next year's* :-). -- "...the Jedi learned early on what language the universe was programmed in. Then they took advantage of an accident of language to obscure this fact from the unwashed. They all affected an inverted lisp. so, a Jedi to be, you the Forth must use." |