A couple ways I've implemented the actual text to make it a little cleaner. All very subjective. Qualified by I nearly always format my statements with a here-doc:
my $sql = <<EOSQL;
SELECT something
FROM atable
WHERE data IN (?)
EOSQL
- Using baby cart
my $sql = <<EOSQL;
SELECT something
FROM atable
WHERE data IN (@{[join ',', ('?') x $size]})
EOSQL
- Using $"
my $sql = do {
my @holders = ('?') x $size;
local $" = ',';
<<EOSQL;
SELECT something
FROM atable
WHERE data IN (@holders)
EOSQL
};
- Using sprintf
my $sql = sprintf <<EOSQL, join ',', ('?') x $size;
SELECT something
FROM atable
WHERE data IN (%s)
EOSQL
I've generally been using #2 recently.
#11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.
| [reply] [Watch: Dir/Any] [d/l] [select] |
Don't do that. Dynamic SQL is bad news.
Every RDBMS has this issue, because stored procedures are not able to use a dynamic list. The way to work this out changes by RDBMS, but all of them are ways it split the values in SQL itself.
Anyway, a simple answer would be to use a recursive CTE to split the values into separate records. Once that is done, IN() or EXISTS can SELECT from the entire CTE.
Here's the basic idea. I quickly looked at mysql functions to write this, but have not tested it at all. Hopefully it shows the basic idea:
WITH RECURSIVE split_csv(x, rest)
AS ( SELECT SUBSTRING_INDEX(?, ',', 1), SUBSTRING(?, FROM INST
+R(?, ',') + 1)
UNION ALL SELECT SUBSTRING_INDEX(rest, ',', 1), SUBSTRING(rest, FROM I
+NSTR(?, ',') + 1)
FROM split_csv)
SELECT something FROM atable WHERE data in (SELECT x FROM split_csv);
| [reply] [Watch: Dir/Any] [d/l] |
Reread the 'dynamic' SQL above. Note that the dynamic component is the number of placeholders, and so there is no attack surface exposed. There are safe and robust ways to do dynamic SQL; it's just always important to understand how to fundamentally limit what could possibly be included. I expect your proposal would bypass the Perl escaping layer entirely, thus increasing the number of attack vectors.
<pedantic>Technically, there is additional attack surface, since you could create some kind of denial of service based upon a really long query, but that's really getting into the weeds.</pedantic>
#11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.
| [reply] [Watch: Dir/Any] |
In addition to the on-point reply by kennethk, it should be noted that MySQL does not implement the SQL:1999 feature for CTEs, including RECURSIVE expressions. This is a well-known bug/limitation (reported in 2006!) and there appears little interest in fixing it upstream.
While CTEs don't appear to be overly beneficial for this problem in terms of SQL input safety, lack of this support is certainly a drawback for those using or considering MySQL as a platform. Given that every other major RDBMS supports CTEs, "Buyer Beware."
| [reply] [Watch: Dir/Any] |