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

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