Currently, the result of ExecutorRun is typically NULL, but if it's
executing a SELECT and you pass a limiting count and the SELECT stops
early because of that limit, then you get back a TupleTableSlot
containing the last tuple processed.
This is pretty ugly.
There is only one call site that
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
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
