Обсуждение: 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