At 10:13 +0100 7/16/02, Tim Bunce wrote: >On Mon, Jul 15, 2002 at 08:57:09PM -0500, Paul DuBois wrote: >> At 0:45 +0100 7/16/02, Tim Bunce wrote: >> >On Mon, Jul 15, 2002 at 09:27:52AM -0500, Paul DuBois wrote: >> >> > file: $CPAN/authors/id/T/TI/TIMB/DBI-1.29.tar.gz >> >> > size: 256485 bytes >> >> > md5: 1811579779bf790e7db5879d302bf4f6 >> >> > >> >> >=head2 Changes in DBI 1.29, 15th July 2002 >> >> > >> >> > NOTE: This release changes the specified behaviour for the >> >> > : fetchrow_array method when called in a scalar context: >> >> >> >> By implication, this change also affects selectrow_array()? >> >> Just checking. >> > >> >No. I wavered either way but decided not to change it in the end. >> >> Hmm... Okay, then something seems odd in the docs. The section for >> selectrow_array() says: > >: =item C<selectrow_array> >: >: @row_ary = $dbh->selectrow_array($statement); >: @row_ary = $dbh->selectrow_array($statement, \%attr); >: @row_ary = $dbh->selectrow_array($statement, \%attr, @bind_values); >: >: This utility method combines L</prepare>, L</execute> and >: L</fetchrow_array> into a single call. If called in a list context, it >: returns the first row of data from the statement. The C<$statement> >: parameter can be a previously prepared statement handle, in which case >: the C<prepare> is skipped. > >> But if selectrow_array() calls fetchrow_array(), shouldn't it too reflect >> the new behavior? (On the other hand, perhaps the doc is incorrect, since >> in the code, it appears that selectrow_array() really is implemented in >> terms of fetchrow_arrayref() and not fetchrow_array()...) > >Since few sane people would call selectrow_array (or fetchrow_array) in
I don't know if sanity is a criterion here. What matters is that the docs describe what actually can be done or what can be expected. :-) >a scalar context for a select statement with more than one result column, >I'm happy to make change selectrow_array to be consistent with the new >fetchrow_array definition. Especially as I don't have to change code or >break anything :) Okay. Thanks for the clarification. Just a little niggle below: >Both now say: > > If called in a scalar context for a statement handle that has more > than one column, it is I<undefined> whether the driver will return > the value of the first column of the last. So don't do that. ....first column *or* the last... ? > Also, in a scalar context, an C<undef> is returned if there are no > more rows or if an error occurred. That C<undef> can't be distinguished > from an C<undef> returned because the first field value was NULL. > For these reasons you should exercise some caution if you use > [this method] in a scalar context.
