apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Donovan <donov...@bellatlantic.net>
Subject Re: sqlite3 and postgresql
Date Sat, 17 May 2008 14:03:53 GMT
Bob Rossi wrote:
> Hi,
> 
> I've been using sqlite3 dbd for some time now. I find that the function
> apr_dbd_get_row,
>   http://apr.apache.org/docs/apr-util/trunk/group___a_p_r___util___d_b_d.html#gd4cdc5f4e8981b93f5a467a8c8a768f1
> is 1 based. That is, 1 is the first row returned from a query. However,
> I just started using postgresql, and I find that apr_dbd_get_row is 0
> based. That is, 0 is the first row returned from the query.
> 
> Is this expected behavior? Perhaps a bug in my test? The test is,

The doc doesn't specify, and the current dbd drivers appear to be inconsistent about whether
rownum 
is 1-based or 0-based for random access:

APR 1.2 drivers

   sqlite2 1-based (the driver specifically adjusts it to be 1-based)
   sqlite3 1-based (the driver specifically adjusts it to be 1-based)
   pgsql   0-based
   mysql   0-based (per MySQL docs for mysql_data_seek)

APR 1.3 drivers

   oracle  1-based (per Oracle docs for "Scrollable Cursors in OCI" and OCIStmtFetch2)
   freetds 1-based (per SQLServer docs for dbgetrow function)

I think this is a valid bug.  Personally I would favor 1-based.  The majority of dbd drivers
already 
do this, and most users would expect the traditional SQL meaning of "row number", i.e. 1-based
row 
numbers.

-tom-

Mime
View raw message