SQL::Interp is an excellent tool to help build SQL. It can be especially pleasant to use from DBIx::Simple. Combining the two, you can do this:
 $result = $db->iquery("SELECT * FROM foo WHERE a = ",\$b)
It's easy to read, and $b will automatically be translated into a bind variable. My concern is that on a number of occasions I have seen well meaning programmers do this instead:
 $result = $db->iquery("SELECT * FROM foo WHERE a = ",$b)
The difference is the backslash before the $b. The rub is that the code produces the same result either way, but the second format has possibly introduced an opportunity for a SQL injection attack. What suggestions do you have for how SQL::Interp might detect such cases, so that it can warn or die? Here are some brainstorms I've thought of, possibly activated only when a "strict mode" is enabled.
  1. Scalars are no longer allowed at all. Instead, you would use something like: "sql('SELECT * from foo WHERE a = '),\$b"
  2. Assume any two strings in a row is a mistake...you could always concatenate them instead.
  3. Parse the SQL sufficiently to understand where bind variables *should* be and then make sure they are used there.
Each option has its drawbacks, but does one stand out to you as being better? What other ideas can you think of to addres s this?

In reply to Improving the security of SQL::Interp by markjugg

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":