Re: JSON for PG 9.2

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Abhijit Menon-Sen <ams(at)toroid(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: JSON for PG 9.2
Date: 2012-01-31 14:35:03
Message-ID: CAHyXU0ws+7NYZJ3rFvvO39jiBUL-=S+Mvpsqg_g3bDz0LxA71A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jan 30, 2012 at 9:37 AM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> 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;

yup -- although I'd probably write it like this most of the time:
select array_to_json(array(
<query>
));

if we did have a 'query_to_json', the array() constructor would be a
lot more pleasant to to deal with than a textual query for obvious
reasons even though it's highly irregular syntax. however, since
arrays can already handle it, I wouldn't miss it at all.

merlin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2012-01-31 14:44:19 Re: Group commit, revised
Previous Message Robert Haas 2012-01-31 14:28:38 Re: [v9.2] Add GUC sepgsql.client_label