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
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 :)
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.
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.
> 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?
Yeap. Thanks!
Tim.
> >
> >> > : 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).
> >>
>
