I think the problem though is that the eval isn't dying. It's just warning. $ret thus is set to the return of whatever the fetch method he used. If his eval died, we shouldn't see an error message at all, it should go into $@.

Sorry if I'm missing something or if we're talking about two slightly different things.

No,
cause the result of the query is the warning, which is a string, so the eval gives back a string and does not die, cause it has not interpreted the query but the query result.
Have a nice day
All decision is left to your taste

If things are as you say they are, I would consider that a bug with DBI. A method should never, upon failure, simply return the error message in a string. That makes true/false type tests impossible. If I am writing a method that fails, I might print out a warning via warn, sure, but I would ALWAYS return a false value from that method so that people using my code can test for success/failure based upon that. That is very brain-dead if (as you seem to indicate), DBI is returning a string where ordinarily we would see an array reference or a boolean true/false indication.

If the method under normal circumstances is returning a false value, and correctly printing its warnings via warn, this is not touched by eval:

$a = eval { warn "some warning\n"; };  # "some warning" to STDERR

print "a=$a\n";   # 1 ('warn' succeeds)
print "@=$@\n";   # <undefined>
[download]

We have to trap $SIG{__WARN__} if we want to capture the "some warning" text. Otherwise it's printed straight to STDERR, even if we're in an eval block. Eval doesn't "return" the warning, it returns whatever its code returns (in this case, whatever selectcol_arrayref returns). I think you're mistaken.