On Mon, Jan 30, 2012 at 9:37 AM, Andrew Dunstan <and...@dunslane.net> wrote: > On 01/30/2012 09:54 AM, Abhijit Menon-Sen wrote: >> >> At 2012-01-27 09:47:05 +0530, a...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers