Re: Is it ever legal (should be supported) to issue a non select in selectall_arrayref?

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;

--