My point is that some of the aggregate functions only return refs, and don't have a counterpart that returns an actual array. selectcol_arrayref, fetchall_arrayref, fetchrow_hashref to name a few. So, you have to either dereference them when you make the call, or use an intermediate variable, or dereference them as you use them (and the first is usually most convenient for me; it makes the things I do later a lot more readable).

Not quite, mine says 'row' not 'col' as your first example does. Are you trying to avoid using bind_parm/bind_col? I find they are most useful and very easy to maintain. A good editor with a column mode that can insert sequence numbers helps (like ultraedit) with binding the references.

Selecting a column rather than a row can be very useful. For example, suppose I want a list of every distinct value in one of my database fields. I can use selectcol_arrayref along with a SELECT DISTINCT statement to slurp the whole column into an array. Any of the other DBI functions would force you to use looping structures or list operators on your fetched data to get the same result, and you would have to bother with prepare, execute, fetch and finish.

If you are using any of the database handle methods (as opposed to statement handle methods), you cannot bind variables becuase you never prepare the statement; DBI does it all for you. This works wonderfully for a one-shot query, where there is no reason to bind variables.