because I'll be passing it to a sql statement as part of an "IN" clause

My first suggestion is to not re-invent the wheel, have a look at SQL::Abstract (example).

DBI provides quote* and quote_identifier, this is the very least you should do - don't go and try to quote the strings yourself.

Also, as an aside, you should always use placeholders wherever possible - see Bobby Tables.

* Update:

use warnings;
use strict;
use DBI;

# just using an SQLite in-memory DB as an example here
my $dbh = DBI->connect("dbi:SQLite:dbname=:memory:", '', '',
    { RaiseError=>1, AutoCommit=>0 } );

my @values = qw/ CAT DOG BIRD COW bl'ah /;
my $str = join ',', map { $dbh->quote($_,'VARCHAR') } @values;
print $str, "\n";

__END__

'CAT','DOG','BIRD','COW','bl''ah'
[download]

don't go and try to quote the strings yourself.

Come on, why not? This is being a bit dogmatic, isn't it?

While I certainly agree that using the functionalities provided by DBI or other modules such as SQL::Abstract is a good idea (and I upvoted your post), knowing how to do it in core Perl is also a good idea, IMHO. After all, Perl is supposed to be a very good language at string handling. Do you really think that doing it the Java way is better?

For example:

my $str = join ', ', map { "'$_'" } split /,/, "CAT,DOG,BIRD,COW";    
+ # -> 'CAT', 'DOG', 'BIRD', 'COW'
[download]

or even better:

my $str = "CAT,DOG,BIRD,COW";
$str =~  s/\b/'/g;     # -> 'CAT','DOG','BIRD','COW'
[download]

Both examples took me less than 10 seconds to write and test (under the debugger). Looking up the documentation for either of the two modules would probably take me at least 10 or 15 minutes, so 60 to 100 times longer.

To me, using a module for something that can be done with a regex requiring less than ten keystrokes is a bit of over-engineering.

Come on, why not? This is being a bit dogmatic, isn't it?

Not really. When you know the broken or wonky data you'll get 100% of the time, sure, why not. But data in the wild is rarely predictable and the best advice to that end is suggesting the most robust solutions. The same reason we don't recommend regular expressions for parsing HTML. Most of the time it is actually fine but most of the time is a lousy way to live. :P

Thanks! Works perfectly