Date: Thu, 4 Feb 2021 17:38:52 +0100
From: Denis Laxalde <denis.laxalde@dalibo.com>
To: Christophe Pettus <xof@thebuild.com>
Cc: Daniele Varrazzo <daniele.varrazzo@gmail.com>, psycopg@postgresql.org
Subject: Re: about client-side cursors
Message-ID: <20210204163852.5mwvddtr74aw6wrh@dalibo.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>
 <3BA6B9FE-9A00-4F04-9C0B-263EE4301985@thebuild.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <3BA6B9FE-9A00-4F04-9C0B-263EE4301985@thebuild.com>
User-Agent: NeoMutt/20180716
Precedence: bulk

Christophe Pettus a écrit :
> 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().

Is this related to prepared statements in the extended query protocol?
(Then, I'd argue that both preparation and execution steps would involve
IO. But if it's not a cursor, we should use a different name, as
postgresql doc does.)

> It doesn't seem a good idea to guarantee
> forever that .execute() will *never* do I/O without a database-side
> cursor.

Currently, it seems to me that .execute() always do IO with or without a
database cursor.