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 even examines the result, and that's
functions.c. With the rewrite that I plan to commit shortly,
functions.c doesn't actually use the slot contents --- it expects
the tuple to have been put into a tuplestore by the DestReceiver
mechanism. It's currently checking the result to determine whether
it obtained a tuple or not, but that could easily be reported by the
DestReceiver code (... or we could make tuplestores a bit more helpful
about reporting if they have any content or not).
So I'm thinking that we could and should make ExecutorRun's API a little
less baroque. Two possibilities are:
* Just return void. (Then we need a few more lines in functions.c.)
* 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.
Comments? I'm leaning a bit towards the first way because minor
convenience for functions.c doesn't seem to justify bending a core
executor API.
regards, tom lane
