Update:Umm, I DID use prepare_cached :) DBI won't do the hard work for me, though, unless I make sure the statement stays the same. And the statement won't stay the same unless I sort the field names (DBI's prepared_cached uses the entire SQL statement as a hash key). It also helps, though, to keep statements the same so that the db itself (well, some db's) can cache the statement w/o re-parsing the statement over several executions of the same script (not as efficient as perl/DBI caching, but every bit helps.

I did not know you could do that join that way w/o map though :)

You can use prepare_cached to cache it automatically. Let DBI do the hard work for you!

-- Randal L. Schwartz, Perl hacker

IIRC, the DBI spec doesn't support using placeholders for the column names, only values. Programming the Perl DBI, p 221 says the following:

With most drivers, placeholders can't be used for any element of a statement that would prevent the database server from validating the statement and creating a query execution plan for it. For example:

"SELECT name, age FROM ?"       #wrong (will probably fail)
"SELECT name, ?   FROM people"  #wrong (but may not 'fail')
[download]

While this may not fail with some databases like MySQL, it *may* fail on databases like Oracle that natively support placeholders. (can anyone confirm this?)

Here's what happens under oracle:

# fails under oracle
my $sth = $dbh->prepare("select name, age from ?")     

# does not fail under oracle, but gives wrong results.
my $sth = $dbh->prepare("select name, ? from table")  

# outputs n copies of the string "age", for n rows in table.
$sth->execute("age")
[download]

___
-DA