Content-Type: text/plain; charset="iso-8859-15"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: psql's FETCH_COUNT (cursor) is not being respected for CTEs
From: "Daniel Verite" <daniel@manitou-mail.org>
To: "Laurenz Albe" <laurenz.albe@cybertec.at>
Cc: PostgreSQL Hackers
 <pgsql-hackers@postgresql.org>,
 Tom Lane
 <tgl@sss.pgh.pa.us>,
 Robert Haas
 <robertmhaas@gmail.com>,
 Jakub Wartak <jakub.wartak@enterprisedb.com>
In-Reply-To: <7a3a478be2a16465ac93ba01b13e1081568cbbd9.camel@cybertec.at>
Date: Mon, 01 Apr 2024 18:09:55 +0200
Message-Id: <e055dafc-8f4c-4243-a209-e05e986e8284@manitou-mail.org>
Archived-At: <https://www.postgresql.org/message-id/e055dafc-8f4c-4243-a209-e05e986e8284%40manitou-mail.org>
Precedence: bulk

	Laurenz Albe wrote:

> I had a look at patch 0001 (0002 will follow).

Thanks for reviewing this!

I've implemented the suggested doc changes. A patch update
will follow with the next part of the review.

> > --- a/src/interfaces/libpq/fe-exec.c
> > +++ b/src/interfaces/libpq/fe-exec.c
> > @@ -41,7 +41,8 @@ char     *const pgresStatus[] =3D {
> >     "PGRES_COPY_BOTH",
> >     "PGRES_SINGLE_TUPLE",
> >     "PGRES_PIPELINE_SYNC",
> > -   "PGRES_PIPELINE_ABORTED"
> > +   "PGRES_PIPELINE_ABORTED",
> > +   "PGRES_TUPLES_CHUNK"
> >  };
>=20
> I think that PGRES_SINGLE_TUPLE and PGRES_TUPLES_CHUNK should be next to
> each other, but that's no big thing.
> The same applies to the change in src/interfaces/libpq/libpq-fe.h

I assume we can't renumber/reorder existing values, otherwise it would be
an ABI break. We can only add new values.

> I understand that we need to keep the single-row mode for compatibility
> reasons.  But I think that under the hood, "single-row mode" should be the
> same as "chunk mode with chunk size one".

I've implemented it like that at first, and wasn't thrilled with the result.
libpq still has to return PGRES_SINGLE_TUPLE in single-row
mode and PGRES_TUPLES_CHUNK with chunks of size 1, so
the mutualization did not work that well in practice.
I also contemplated not creating PGRES_TUPLES_CHUNK
and instead using PGRES_SINGLE_TUPLE for N rows, but I found
it too ugly.


Best regards,
--=20
Daniel V=E9rit=E9
https://postgresql.verite.pro/
Twitter: @DanielVerite