Sergei Golubchik added a comment - 2014-12-04 11:53 removed completely

Richard Bensley added a comment - 2017-08-11 10:31 - edited @serg, are we going to see a return of this? Or something similar? Parameterised stored procedure SQL would be very VERY useful for dynamic table names, infile/outfile names, etc.

Sergei Golubchik added a comment - 2017-08-12 09:23 it's not about parameterised stored procedure SQL, it's output parameters in PREPARE, dynamic SQL.

Richard Bensley added a comment - 2017-08-14 13:10 - edited Hi @serg, yes I understand.I see there were some great changes made in MDEV-10866 . This is roughly what I mean, instead of create extremely large concat statements for analytics work loads to generate new tables and outfiles. e.g: SET @source_table=source_table_name; SET @new_table_name=CONCAT("source_table_name", CURDATE());   PREPARE stmt FROM "CREATE TABLE @new_table AS SELECT ... FROM @source_table"; Also for outfiles! PREPARE out_stmt FROM "SELECT * FROM @table INTO OUTFILE '@outfile_name' @TERMINATION_PARMATERS;" Does that make sense? Our analytics sql is hundreds of lines long, I generally wrap SQL with something like python to generate data instead of using stored procedures.

Sergei Golubchik added a comment - 2017-08-14 15:46 It makes sense. But the problem is that a parameter ­— OUT or IN, in PREPARE or in the protocol level prepared statements, even in stored procedures — it's an expression and can be used anywhere where an expression is allowed. In particular, table names cannot be parameters.