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