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: 4F26B922.7000000@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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.

Cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

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