> > for that, we get what exactly? Fetching one row at a time is
> > *guaranteed* to be inefficient. The correct response if that bothers
> > you is to fetch multiple rows at a time, not to make a less robust
> > protocol.
> I don't feel strongly either way on this one, but IIRC the SQL standard
> for cursors only specifies fetching one record at a time (at least that
> is how MSSQL and DB2 implement it). Thus portable code is likely to
> only fetch one record at a time. The current row description isn't too
> big, but with the changes being suggested it might become so.
Yes, I think it should be the responsibility of the higer level interfaces
(ODBC, esql/c, ...) to fetch rows in optimal packets (e.g. 4-16k at a time).
This is what other db's interfaces do for you. The first fetch gets a packet
from the db, subsequent fetches are answered from the client side cache until
it is empty, then the next fetch gets the next packet from the db ...
The trick would be to ask for n bytes of row data (maybe a range), which might
be 1 - n rows (or maybe even only part of one row if it is very wide ?).
I think this is one of the things the new protocol should be able to cope with.
Andreas
