Re: [Ruby-DBI-devel] RPC and Postgres Reprise

[Michael N. <uu...@rz...>]

On Sun, Jun 30, 2002 at 10:02:00PM -0500, Dave Thomas wrote:
> 
> Somewhat lamely I posted the lack of a row count with Postgres #do as
> a bug, then went back through the mailing list archives to see that it
> had been discussed back in April. However, I didn't see a resolution.
> 
> Is this something that can be addressed? If I had a vote, I'd go with
> the option that assumed a #do was used with a none-SELECT statement.

Please correct me if I'm wrong or I misunderstood something.

Method #do returns PGresult#num_tuples, i.e. the number of tuples in the query result.
But that's not what #do in other DBDs return; num_tuples != rows processed count. 
Furthermore #do is usually not called with a SELECT statement, so I don't think that 
anyone is depending on the return value of method #do. 

Statement#rows also returns PGresult#num_tuples, but should return the rows processed count
instead.

So what do you (and others) suggest?

- Add a method to return the number of rows in a query result (that is what #rows currently return) 
- Add a method to return the rows processed count

For the first time, I would leave method #rows as is (we can correct it's behaviour later) and
add a method which returns the same value as #rows currently returns, i.e. the number of rows
in a query result. 

Would it suffice to make it a driver specific function (e.g. sth["dbd_rows_in_result"] or 
sth.func("rows_in_result")), as not all databases supports this?

This would be a temporary solution as long as the DBD/DBI specs will get updated.

> Right now, this is something of a problem for me, as I need to check
> the count following an update to ensure integrity of a long-running
> transaction.

Regards,

  Michael