Alexander Lakhin <exclusion@gmail.com> writes:
> 08.04.2024 18:08, Tom Lane wrote:
>> Hmm, the point about recursion is still valid isn't it? I agree the
>> reference to ExecQueryUsingCursor is obsolete, but I think we need to
>> reconstruct what this comment is actually talking about. It's
>> certainly pretty obscure ...
> Sorry, I wasn't clear enough, I meant to remove only that reference, not
> the quoted comment altogether.
After looking at it, I realized that the comment's last sentence was
also out of date, since SendQuery() isn't where the check of
gexec_flag happens any more. I concluded that documenting the
behavior of other functions here isn't such a hot idea, and removed
both sentences in favor of expanding the relevant comments in
ExecQueryAndProcessResults.
While doing that, I compared the normal and chunked-fetch code paths
in ExecQueryAndProcessResults more carefully, and realized that the
patch was a few other bricks shy of a load:
* it didn't honor pset.queryFout;
* it ignored the passed-in "printQueryOpt *opt" (maybe that's always
NULL, but doesn't seem like a great assumption);
* it failed to call PrintQueryStatus, so that INSERT RETURNING
and the like would print a status line only in non-FETCH_COUNT
mode.
I cleaned all that up at c21d4c416.
BTW, I had to reverse-engineer the exact reasoning for the cases
where we don't honor FETCH_COUNT. Most of them are clear enough,
but I'm not totally sure about \watch. I wrote:
+ * * We're doing \watch: users probably don't want us to force use of the
+ * pager for that, plus chunking could break the min_rows check.
It would not be terribly hard to make the chunked-fetch code path
handle min_rows correctly, and AFAICS the only other thing that
is_watch does differently is to not do SetResultVariables, which
we could match easily enough. So this is really down to whether
forcing pager mode is okay for a \watch'd query. I wonder if
that was actually Daniel's reasoning for excluding \watch, and
how strong that argument really is.
regards, tom lane