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

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

On Mon, Jul 01, 2002 at 08:34:26AM -0500, Dave Thomas wrote:
> Michael Neumann <uu...@rz...> writes:
> 
> > 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.
> 
> I'm suggesting changing #do to return the number of rows processed
> by non-select statements. I think this would be consistent with the
> intent.

Yes, of course.

> If you need the number of rows returned by a select, there are (many)
> other ways to do it. But right now there's no way to find the number
> affected by an update or a delete.
> 
> I'd rather not see a driver-specific method: this is a pretty
> fundamental feature, and making it non-portable would be a shame.

I've now changed method Statement#rows (which is called and returned by 
Database#do) to return the Row Processed Count (affected rows).
Old behaviour is still available through method Statement#['pg_row_count'].

Both changes are in -current (as well as license change from GNU GPL to BSD).

Regards,

  Michael