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

On Fri, Jun 17, 2011 at 04:11, David Nicol <[email protected]> wrote:

> Thanks-- the proposed docpatch was a trial balloon to get this answer.
> Here's copy for a revised proposed patch:
>
> 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 called within an C<eval> block will always work.
>


Doesn't $sth->{NUM_OF_FIELDS} tell you whether the statement is something
that returns values or not?  It's zero for anything that isn't similar to a
SELECT, and positive for any statement like a SELECT (or, for at least some
DBMS, things like EXECUTE PROCEDURE where the procedure returns values)?

The only thing I'm not sure about is whether $sth->{NUM_OF_FIELDS} is always
set by $dbh->prepare, or whether some DBMS can't set it until you do
$sth->execute.



>  On Fri, Jun 17, 2011 at 2:51 AM, Martin J. Evans
> <[email protected]> wrote:
> >
> > So the proposed change saying
> >
> > "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."
> >
> > I don't see how DBD::ODBC is supposed to implement that. fetch is just an
> > alias for fetchrow_arrayref. There is fetch and nothing else. If you call
> > selectall* it ends up in dbd_st_fetch, if you call fetch it ends up in
> > dbd_st_fetch.
> >
> > So the question becomes which is right DBD::Sybase behaviour or
> DBD::ODBC.
> >
> > Martin
>



-- 
Jonathan Leffler <[email protected]>  #include <disclaimer.h>
Guardian of DBD::Informix - v2011.0612 - http://dbi.perl.org
"Blessed are we who can laugh at ourselves, for we shall never cease to be
amused."