Re: Another swing at JSON
Joey Adams <joeyadams3.14159@gmail.com>
From: Joseph Adams <joeyadams3.14159@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>, Josh Berkus <josh@agliodbs.com>
Cc: pgsql-hackers@postgresql.org
Date: 2011-03-29T02:24:10Z
Lists: pgsql-hackers
Attachments
- add-json-contrib-module-20110328-2.patch (text/x-patch) patch
On Mon, Mar 28, 2011 at 2:17 PM, Robert Haas <robertmhaas@gmail.com> wrote: > Well, one thing you'll need to do is rework it for the new 9.1 > extensions interface. Done. The new extension interface isn't exactly compatible with the old, so I dropped support for PostgreSQL 8.4 from the module. I suppose I could maintain a back-ported json module separately. On Mon, Mar 28, 2011 at 7:44 PM, Josh Berkus <josh@agliodbs.com> wrote: > On 3/28/11 10:21 AM, Joseph Adams wrote: >> Currently, there are no functions for converting to/from PostgreSQL >> values or getting/setting sub-values (e.g. JSONPath). However, I did >> adapt the json_stringify function written by Itagaki Takahiro in his >> patch ( http://archives.postgresql.org/pgsql-hackers/2010-09/msg01200.php >> ). > > Would it be possible for you to add a TODO list for JSON support to the > wiki? We have some potential GSOC students who are interested in > working on JSON support. What exactly should go on the TODO list? Adding more features to this JSON data type implementation (and eventually merging some/all of it into core)? Or doing a comparative analysis (benchmarking, etc.) of the ~seven JSON data type implementations floating around? Since I'm not sure what was decided regarding an efficient binary internal representation, I don't know what we should write on the TODO list. In my humble (and biased) opinion, we should review and commit my JSON data type code as a starting point. Then, a GSoC student could work on features (e.g. value conversion, JSONPath), integration (e.g. moving to core, EXPLAIN FORMAT JSON, PL/Js, etc.), and improvements (e.g. a binary internal representation). Thoughts? Joey Adams