Hi Sergei, On 05/26/2014 04:48 PM, Sergei Golubchik wrote: <skip>
Yes, it's a detail. My point was that we shouldn't have two implementations for the same feature (arbitrary transformation of the query result). So either we reuse the code for procedures, or we do a new implementation and move PROCEDURE ANALYSE to use it.
By the way, JSON is not really an arbitrary transformation. Well, it is a transformation, but not very arbitrary :) Another way to implement this would be to have a GROUP_CONCAT-alike aggregate function, so SELECT a,b FROM t1 FOR JSON; is automatically mapped into: SELECT JSON_CONCAT(a,b) AS JSON FROM t1; A function like this would give even more flexibility, e.g. having two or more JSON-formatted columns in the same result set: SELECT group_ID, JSON_CONCAT(a,b), JSON_CONCAT(c,d) FROM t1 GROUP BY group_ID; So we have these ideas: 1. A session variable. 2. SELECT ... FROM t1 FOR JSON 3. SELECT JSON_CONCAT() FROM t1 The last one seems to be the most flexible. And the fist one is the least flexible. <skip>