I'm not 100% sure about the assertion about calling fetch on an executed non-select statement handle being defined to reliably return false, as in no-more-data as part of the standard. If C<fetch*> isn't really defined to behave the same with a non-SELECT as with a SELECT that simply doesn't return any rows, like I think it is but not with certainty, the following is my submission as a patch to DBI.pm.
--- a/DBI.pm Sat Jun 11 16:19:30 2011 -0500 +++ b/DBI.pm Sat Jun 11 16:38:01 2011 -0500 @@ -4621,6 +4621,16 @@ You can specify a maximum number of rows to fetch by including a 'C<MaxRows>' attribute in \%attr. +=head3 On use of non-C<SELECT> SQL in C<select*_*> methods + +While some drivers support statements other than C<SELECT> in the above-listed +convenience functions, others do not. Requirement of this facility is not defined +by the DBI interface standard. The C<do> method is provided for non-C<SELECT> +statements. When you really don't know if the statement you have in a variable +is going to be a C<SELECT> or not, unrolling the process into C<prepare>,C<execute>, +and some C<fetch> variant will always work, as C<fetch> is defined to return +no data when called on executed non-C<SELECT> statement handles. + =head3 C<prepare> $sth = $dbh->prepare($statement) or die $dbh->errstr; --
