On Tue, Jul 16, 2002 at 09:23:41AM -0500, Paul DuBois wrote: > 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... ? Yeap, Thanks. Tim. p.s. Apologies to all for the delay in addressing problems reported with 1.29 (esp re DBD::Oracle). I've been a but too busy the last coupld of days to get to it. Hopefully tomorrow.
