maria-developers team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxx>]

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