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: <20210204111647.4s3qie5cnassksa5@dalibo.com>
Date: Thu, 4 Feb 2021 06:44:07 -0800
Cc: Daniele Varrazzo <daniele.varrazzo@gmail.com>,
 psycopg@postgresql.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <BAB9FCFC-96F6-48E2-98EA-FF851AA6C884@thebuild.com>
References: <20210203161548.vkhu3qkpvmgvyhik@dalibo.com>
 <CA+mi_8a1ery2xvb+AdxMtVXydOdGC7wRMnfXNAvk8v73HsLFyw@mail.gmail.com>
 <20210204111647.4s3qie5cnassksa5@dalibo.com>
To: Denis Laxalde <denis.laxalde@dalibo.com>
Precedence: bulk


> On Feb 4, 2021, at 03:16, Denis Laxalde <denis.laxalde@dalibo.com> =
wrote:
> But, unless I missed it, the PEP does not state how to implement query
> execution and result fetch operations if the database does not need a
> cursor.

First, any change like this would have to maintain their current API =
essentially forever, unless psycopg3 represents a completely =
incompatible break with the psycopg2 interface.  There is an enormous =
body of code out there that uses the current cursor() interface for =
client-side cursors.

Second, it would be very unwise to make guarantees about when these =
operations interact with the database.  I think that any client =
application should expect that both cursor.execute() and =
cursor.fetchone()/.fetchall() are asynchronous operations, and code =
appropriately.
--
-- Christophe Pettus
   xof@thebuild.com