Re: JSON for PG 9.2 - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: JSON for PG 9.2
Date
Msg-id 4F26B922.7000000@dunslane.net
Whole thread Raw
In response to Re: JSON for PG 9.2  (Abhijit Menon-Sen <ams@toroid.org>)
Responses Re: JSON for PG 9.2  (Merlin Moncure <mmoncure@gmail.com>)
Re: JSON for PG 9.2  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers

On 01/30/2012 09:54 AM, Abhijit Menon-Sen wrote:
> At 2012-01-27 09:47:05 +0530, ams@toroid.org wrote:
>> I've started reviewing this patch, but it'll take me a bit longer to go
>> through json.c properly.
> OK, I finished reading json.c. I don't have an answer to the detoasting
> question in the XXX comment, but the code looks fine.


Looking at somewhat analogous code in xml.c, it doesn't seem to be done 
there. SO maybe we don't need to worry about it.

>
> Aside: is query_to_json really necessary? It seems rather ugly and
> easily avoidable using row_to_json.
>

I started with this, again by analogy with query_to_xml(). But I agree 
it's a bit ugly. If we're not going to do it, then we definitely need to 
look at caching the output funcs in the function info. A closer 
approximation is actually:
   SELECT array_to_json(array_agg(q))   FROM ( your query here ) q;


But then I'd want the ability to break that up a bit with line feeds, so 
we'd need to adjust the interface slightly. (Hint: don't try the above 
with "select * from pg_class".)


I'll wait on further comments, but I can probably turn these changes 
around very quickly once we're agreed.


Cheers

andrew



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Group commit, revised
Next
From: Jeff Janes
Date:
Subject: Re: Simulating Clog Contention