Gregory Stark <[EMAIL PROTECTED]> writes: > Tom Lane <[EMAIL PROTECTED]> writes: >> * Return the count of tuples processed, probably as a long since that's >> what the input limit-count is. There are potential overflow issues with >> this definition on 32-bit machines, though that's not going to affect >> functions.c since it passes a limit of 1 tuple in the cases where it >> needs to examine the result, and no one else presently cares at all. >> But the possibility of overflow might limit the usefulness of this >> definition in other scenarios.
> And what would that mean for a cursor which was read forward and backward? Nothing really; the cursor code does its own counting. Hmm ... now that I look at it, there is already a counter estate->es_processed, so there's really no reason for ExecutorRun to return anything at all. es_processed is only uint32, so someday we might want to widen it, but I think it's not important in current usage. In any case that'd be orthogonal to this discussion. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers