maria-developers team mailing list archive

[Alexander Barkov <bar@xxxxxxxxxxx>]

  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>