Hi, Alexander! On May 26, Alexander Barkov wrote:
SELECT id,name,address FROM users FOR JSON;
This can be built on the existing functionality.
"FOR JSON" is a result filter, something that gets the result of a query and transforms it into something different, different set of columns even. Naturally, in MySQL language this should've been
SELECT id,name,address FROM users PROCEDURE JSON;
We can make these two as synonyms:
SELECT id,name,address FROM users PROCEDURE JSON;
and
SELECT id,name,address FROM users FOR JSON;
so internally they map into the same thing.
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.
Although, seriously, I don't expect PROCEDURE JSON to work out of the box - procedure api is way too old and hardly ever used. I woldn't be surprised if it's broken in many subtle ways.
At least this does not work:
select * from (select user from mysql.user procedure analyse())\G ERROR 1221 (HY000): Incorrect usage of PROCEDURE and subquery So it does need some hacking.
No wonder - procedures were added many years before subqueries :)
I think having JSON in subselects is important, to be able to get one JSON value per record when needed (instead of a single huge JSON value with one row and one column bundling all records).
Yes, sure. I totally agree with that. Regards, Sergei