> It would be both unpleasant to implement, very slow, and couldn't be
> done with complete accuracy. There is no way to computer the
> number of
> records to be fetched without materializing each record.

Bummer. I thought there might have been a stage during query execution(after
query compilation by cmp.cpp, and before records were peeled off by rse.cpp)
where a variable was incremented (+=1) during the query...doh!

> Then there are
> two ways to go. One is to throw the records away and rematerialize
> them. The other is to try and save the materialized records. The
> latter if frought with peril since the host program is free
> to update a
> record, and the update would need to be tracked. Regardless
> of how that
> problem is handled, there is also the case where a record is
> modified by
> a different request in the same transaction, taking it out of
> the record
> set.

Yup. A quick way to blow something up.

This would lead to the condition where the number of records

> reported and the number actually fetch differ. And then there's the
> problem of a new record inserted that should belong to the
> record set.
> Depending on where it ended up in the data pages maybe it would be
> found, maybe not.

I see your point.
As a hypothetical scenario, if tracking changes wasn't done, accuracy wasn't
paramount, and a counter was installed(or found to do the job) inside the
query execution loop, and it was bubbled up to the interface via an existing
framework that didn't requre new parameters added to function decls(as a
non-blocking exception/message of some sort)...

Na, forget the question. I feel too naive in the code yet.
I'll do some more reading...

Nige.