Обсуждение: Changing the result of ExecutorRun

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

Tom Lane <tgl@sss.pgh.pa.us> 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?

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about
EnterpriseDB'sPostgreSQL training!
 

Gregory Stark <stark@enterprisedb.com> writes:
> Tom Lane <tgl@sss.pgh.pa.us> 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