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 _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp