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
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?! |