très laid cludge j'ai peur que MySQL sprocs Ne supporte actuellement type tableau params:
Exemple d'appel:
mysql> call foo('2,4,6');
+---------+----------+
| user_id | username |
+---------+----------+
| 2 | b |
| 4 | d |
| 6 | f |
+---------+----------+
3 rows in set (0.00 sec)
script complet:
drop table if exists users;
create table users
(
user_id int unsigned not null auto_increment primary key,
username varchar(32) unique not null
)
engine=innodb;
insert into users (username) values ('a'),('b'),('c'),('d'),('e'),('f'),('g');
drop procedure if exists foo;
delimiter #
create procedure foo
(
in p_id_csv varchar(1024)
)
proc_main:begin
declare v_id varchar(10);
declare v_done tinyint unsigned default 0;
declare v_idx int unsigned default 1;
if p_id_csv is null or length(p_id_csv) <= 0 then
leave proc_main;
end if;
-- split the string into tokens and put into an in-memory table...
create temporary table ids(id int unsigned not null)engine = memory;
while not v_done do
set v_id = trim(substring(p_id_csv, v_idx,
if(locate(',', p_id_csv, v_idx) > 0,
locate(',', p_id_csv, v_idx) - v_idx, length(p_id_csv))));
if length(v_id) > 0 then
set v_idx = v_idx + length(v_id) + 1;
insert into ids values(v_id);
else
set v_done = 1;
end if;
end while;
select u.* from users u
inner join ids on ids.id = u.user_id
order by u.username;
drop temporary table if exists ids;
end proc_main #
delimiter ;
call foo('2,4,6');
Ceci est une vulnérabilité d'injection SQL dans la fabrication. –
Événement SI il y avait une possibilité d'injection SQL, essayer une programmation défensive dans un proc stocké (ou quelque chose qui n'a rien à voir avec la base de données ou ses données) conduirait probablement à un désordre impossible à maintenir. Je dis que c'est au programmeur de passer des paramètres valides ou d'éviter les procédures stockées si possible. –
Le problème n'est pas stocké procédures. C'est évaluer le code qui est généré, en partie, par l'entrée de l'utilisateur. C'est une idée terrible dans * tout * langage, pas seulement SQL. Comme cela a été démontré très habilement par f00 ci-dessus, ce problème peut être résolu en utilisant SQL sans introduire de vulnérabilité, comme le fait votre code. –