Yep. It's understandable that you need to construct an SQL query dynamically. I had to do the same thing when search parameters were given through an XML. But since this kind of Structured information is exactly what perl is for, there are ways to make your code do more with less. The code I use:

my $db_query = 'SELECT ';
$db_query .= join ', ', @select;
$db_query .= ' FROM ';
$db_query .= join ', ', @from;
$db_query .= ' WHERE ';
$db_query .= join ' AND ', @limits;
$db_query .= ';'; # Not mandatory, just for good order.
[download]

The way I did this, I had XML tags stating:

• What to show (push @select, foo)
• What table (push @from, bar)
• Search criterion, for example <above>30</above>, that was sent to the matching subroutine to construct the baz for push @limits, baz.
• Search criterion expected from CGI parameters - in which case I used CGI.pm's auto escaping to avoid the escaping problems (although it's not so smooth so test thoroughly).

Of course, your construction need are probably different, so customize happily. What I really wanted to say was use map, join, reduce, and other list functions instead of loop and concatenation.

As for modules, sometimes it's just quicker, and surely more fun (if you're not under a deadline) to do your own coding, and you always learn from it. Well, TIMTOWTDI...

PS - If you're expecting outside input throw in extra validation and taint checking code or you'll get errors from the DB or much worse.