Re: [Ruby-DBI-devel] Rows Affected and Postgres

[Gabriel E. <ga...@de...>]

You have good points.  What I don't like about #2 is the inconsistency,
but #3 is a large change to impose.  If rows_affected() was added, and
rows() still worked, but was deprecated for DML, that would give us a
way out that could keep everyone happy.  Then we can obsolete the
affected_rows behavior of rows() after sufficient warning.

As far as I know this only affects PostgreSQL.  I wouldn't want to
impose as large an API change as #3 on users of other DBDs.  I use DBI
in production, as I think more and more businesses are, so API
preservation and measured change are important.

Just my 2 cents.

--Gabriel

> Hi,
>
>
> 2. Add DBI::StatementHandle#num_rows
>    While this is easy, but this make the API less elegant because
>    it force the programmer to remember two different method
>    for the same operation (number of rows processed).
>
> 3. Add special method for DML Query (insert, update, delete)
>    so we can reliably separate Select and Non-Select query.
>    This is reasonable because you can't use row fetching method
>    on DBI::DatabaseHandle#execute('UPDATE something...') result.
>