heres another possibility - without the attributes. With a wrapper class, you can make the interpolate function disappear altogether
...
use SqlStr (alias => 'iDBI');
my $dsn = "dbi:mysql:database=test;user=test;host=localhost;";
my $dbh = iDBI->connect($dsn, { RaiseError => 1, PrintError => 1 });
my $sth = $dbh->prepare('select * from foo');
$sth->execute;
This could be done. I won't make it the only interface into SQL::Interpolate since one might want to use SQL::Interpolate with a modules other than DBI, but providing an optional DBI wrapper as such seems logical.
My biggest concern is that all this interpolation could inadvertently be used to
inject bad SQL into the statement, and the user, whose taking advantage of
your module, would be unaware of such risks, hence more likely to not 'prevent' it.
That said, your pod could 'educate' them on the subject, and you might be able
to add some checks to help prevent it.
I'll add this to the pod in next version. It's hard to say what's the best way is to prevent a user from innocently rewriting a
$dbh->do(qq[UPDATE mytable SET x = ], \$x, qq[WHERE y = ], \$y]);
as
$dbh->do(qq[UPDATE mytable SET x = ] . $x . qq[WHERE y = ] . $y);
apart from some type of taint-mode-like safeguard.
Id be more comfortable with things if you were to use placeholders more fully,
tho there are places it wont work (like an IN @list).
In what ways should more placeholder support be added? Note that
sql_interp qq[SELECT * FROM mytable WHERE x IN ], [EMAIL PROTECTED]
does indeed generate SQL such as
SELECT * FROM mytable WHERE x IN (?, ?, ?)
dependent upon the length of @list.
-davidm
