Re: psql's FETCH_COUNT (cursor) is not being respected for CTEs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alexander Lakhin <exclusion(at)gmail(dot)com>
Cc: Daniel Verite <daniel(at)manitou-mail(dot)org>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>
Subject: Re: psql's FETCH_COUNT (cursor) is not being respected for CTEs
Date: 2024-04-08 20:04:50
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Alexander Lakhin <exclusion(at)gmail(dot)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

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

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Erik Wienhold 2024-04-08 20:30:20 Re: Converting README documentation to Markdown
Previous Message Daniel Verite 2024-04-08 20:03:21 Re: psql's FETCH_COUNT (cursor) is not being respected for CTEs