[DB-SIG] Remaining issues with DB API 1.1

[Greg Stein]

M.-A. Lemburg wrote:
>...
> The updated spec now says:
> """
> fetchmany([size=cursor.arraysize])
>               Fetch the next set of rows of a query result, returning a
>               sequence of sequences (e.g. a list of tuples). An empty
>               sequence is returned when no more rows are available. The
>               number of rows to fetch is specified by the parameter. If it is not
>               given, the cursor's arraysize determines the number of rows to
>               be fetched.
> """

This is good, although we should probably elaborate a bit more: it is
possible that *fewer* than the requested number of rows (via the
parameter or cursor.arraysize) will be returned. Specifically, it will
almost always happen at the "end" of a query. IMO, it should also be
legal mid-query, but we don't need to explicitly state that. (although
we should be clear that returning fewer does *not* mean the
end-of-query... the only determining factor for that is an empty
sequence)

> > No need to specify in the spec exactly _what_ the default should
> > be - it seems sufficient to describe the behaviour - ie, "if not
> > specified", rather than "the default value is xxx"
> 
> Hmm, I don't quite follow you here. Why shouldn't the default
> be defined ? [After all, the 1.0 spec also defined the "default"
> to be cursor.arraysize.]

It should be defined. He's smoking something :-)  Your current text
looks good.

> If we were not to define the default value, then the definition
> of cursor.arraysize would be obsolete w/r to fetchmany():
> """
> arraysize
> ...
> """
> 
> Should we drop the reference to fetchmany() in the above definition ?

Nope.

Cheers,
-g

--
Greg Stein, http://www.lyra.org/