From: Michael Neumann <mneumann@...>
Date: 2003-10-13T03:17:45+09:00
Subject: Re: mysql_num_rows equivalent for DBI?

On Mon, Oct 13, 2003 at 02:24:28AM +0900, Ben Giddings wrote:
> On Sunday, Oct 12, 2003, at 11:08 US/Eastern, Michael Neumann wrote:
> >Try this one:
> >
> >  dbh.execute("SELECT Username FROM Users")['pg_row_count']
> >
> >This is a Postgres-specific function, but should return what you 
> >except.
> 
> Hmm, and there isn't a more general way of doing that, other than 
> returning all entries and doing a .size?

Undoubtedly, this would be a quite useful feature.
Unluckily, this information is not available for every database.
Nevertheless, it's now on my (very long) todo list.

> >What exactly should be a bug? That sth.execute returns [nil]?
> >That's not a bug, but even so should be changed to nil or self.
> 
> The buggy part is that sth.rows returns 0.  From my reading of the DBI 
> documentation (sparse as it is), says that it should return the number 
> of rows processed, or nil.  Another poster said that this variable is 
> used only when doing an update or delete.  If that's the case, it seems 
> like a SELECT statement should set it to nil.  I still think that it 
> should be set to a real value, however.

DBD::Pg's rows method return the result of rows_affected (part of C
interface) which may return 0.  The problem is that I can't simply
return nil when rows_affected returns 0, because a RPC of 0 is a valid
one (DELETE ... WHERE 0=1). So I would have to check wether it's a
query or an update/delete, which can be as simple as =~ /select/i but
occasionally can be much harder.

> As for sth.execute, I really don't know what that should return, but an 
> array containing just nil doesn't seem very useful.

That's just because Ruby returns the last value of a method. I now
return nil instead. 

Regards,

  Michael