Date: Thu, 4 Feb 2021 16:02:03 +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: <20210204150203.iuophq3yx7nzpfzo@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <BAB9FCFC-96F6-48E2-98EA-FF851AA6C884@thebuild.com>
User-Agent: NeoMutt/20180716
Precedence: bulk

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

Sure, that's a valid point. But maintaining this backwards compatibility
does not mean we can't hide the details and advertise a cleaner API for
newcomers or people willing to migrate.

> 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.

If "cursor" is a real database cursor, I agree.