Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
Subject: Re: about client-side cursors
From: Christophe Pettus <xof@thebuild.com>
In-Reply-To: <20210204150203.iuophq3yx7nzpfzo@dalibo.com>
Date: Thu, 4 Feb 2021 07:17:37 -0800
Cc: Daniele Varrazzo <daniele.varrazzo@gmail.com>,
 psycopg@postgresql.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <3BA6B9FE-9A00-4F04-9C0B-263EE4301985@thebuild.com>
References: <20210203161548.vkhu3qkpvmgvyhik@dalibo.com>
 <CA+mi_8a1ery2xvb+AdxMtVXydOdGC7wRMnfXNAvk8v73HsLFyw@mail.gmail.com>
 <20210204111647.4s3qie5cnassksa5@dalibo.com>
 <BAB9FCFC-96F6-48E2-98EA-FF851AA6C884@thebuild.com>
 <20210204150203.iuophq3yx7nzpfzo@dalibo.com>
To: Denis Laxalde <denis.laxalde@dalibo.com>
Precedence: bulk


> On Feb 4, 2021, at 07:02, Denis Laxalde <denis.laxalde@dalibo.com> =
wrote:
>=20
> If "cursor" is a real database cursor, I agree.

But it's not just CURSORs that have this behavior.  libpq allows the =
client to the send the query, and then make separate requests for each =
row, even without a database cursor; this maps almost exactly to =
.execute() and .fetchone().  It doesn't seem a good idea to guarantee =
forever that .execute() will *never* do I/O without a database-side =
cursor.

Having a single convenience method on the connection object that does =
the equivalent of a .execute() and a .fetchall() might be useful, =
though.
--
-- Christophe Pettus
   xof@thebuild.com