On Mon, Mar 28, 2011 at 2:17 PM, Robert Haas <robertmhaas(at)gmail(dot)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(at)agliodbs(dot)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).
In response to
pgsql-hackers by date
|Next:||From: Euler Taveira de Oliveira||Date: 2011-03-29 04:10:52|
|Subject: Re: Open issues for collations|
|Previous:||From: Fujii Masao||Date: 2011-03-29 02:20:48|
|Subject: Re: Problem with streaming replication, backups, and