Skip site navigation (1) Skip section navigation (2)

Re: JSON for PG 9.2

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Abhijit Menon-Sen <ams(at)toroid(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: JSON for PG 9.2
Date: 2012-01-30 15:37:06
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

On 01/30/2012 09:54 AM, Abhijit Menon-Sen wrote:
> At 2012-01-27 09:47:05 +0530, ams(at)toroid(dot)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.



In response to


pgsql-hackers by date

Next:From: hubert depesz lubaczewskiDate: 2012-01-30 15:39:13
Subject: Re: pg_dump -s dumps data?!
Previous:From: Adrian KlaverDate: 2012-01-30 15:34:49
Subject: Re: pg_dump -s dumps data?!

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group