You don't know how much code he would have to refactor to make it all usable in DBI. It might be a day's worth of work, or a month.

Creating a DBI handle will only take a few minutes and can be a test account. This is certainly easier, for a quick fix, than rewriting the whole thing to use DBI.

Perhaps true...though if there is a lot of code, it's going to be a lot of work no matter what (not just creating "a DBI handle"). I imagine theres a lot of code with interpolated varables, e.g.

my $sql = <<EOT
select blah, blahblah
from blah_etc
where foo = '$bar'
EOT
[download]

For the least amount of work, I might use something like Interpolate and turn that in to something like:

my $sql = <<EOT
select blah, blahblah
from blah_etc
where foo = $quote{$bar}
EOT
[download]

(with %quote properly defined through Interpolate)

But even that is a lot of tedious work if there is a lot of SQL to change. I could be wrong, but I don't think it would be much more work to just go ahead and use DBI to execute the SQL and return results.

I've been looking at Interpolate. How would that take care of bad characters in $bar in your example?

---

#my sig used to say 'I humbly seek wisdom. '. Now it says:
use strict;
use warnings;
I humbly seek wisdom.

quote and quote_identifier are both database handle methods.

They have to be, because escaping is handled differently in the various DBs out there. But it's the only safe method that I know of, which is why I recommend it, and recommend refactoring as much as possible at the same time.

If you know another secure methods feel free to offer it.

They have to be, because escaping is handled differently in the various DBs out there

If that was it, they'd be database driver handle methods instead of database handle methods.

Relevant information such as the character encoding can be specific to the actual database, not just to the database driver.