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. > >Tim.
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()...) By the way, the next entry in the docs is for selectrow_arrayref(), which says: =item C<selectrow_arrayref> $ary_ref = $dbh->selectrow_array($statement); $ary_ref = $dbh->selectrow_array($statement, \%attr); $ary_ref = $dbh->selectrow_array($statement, \%attr, @bind_values); This utility method combines L</prepare>, L</execute> and L</fetchrow_arrayref> into a single call. 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. Looks like the three example lines should say _arrayref and not _array? > >> > : The DBI spec used to say that it would return the FIRST field. >> > : Which field it returns (i.e., the first or the last) is now undefined. >> > : This does not affect statements that only select one column, which is >> > : usually the case when fetchrow_array is called in a scalar context. >> > : FYI, this change was triggered by discovering that the fetchrow_array >> > : implementation in Driver.xst (used by most compiled drivers) >> > : didn't match the DBI specification. Rather than change the code >> > : to match, and risk breaking existing applications, I've changed the >> > : specification (that part was always of dubious value anyway). >>
