MIME-Version: 1.0
References: <20210203161548.vkhu3qkpvmgvyhik@dalibo.com>
In-Reply-To: <20210203161548.vkhu3qkpvmgvyhik@dalibo.com>
From: Daniele Varrazzo <daniele.varrazzo@gmail.com>
Date: Wed, 10 Feb 2021 13:43:39 +0100
Message-ID: 
 <CA+mi_8a4A9-fu39sLzvGbeqF9odLBNuyORfMc5K4yv=XgZQjsA@mail.gmail.com>
Subject: Re: about client-side cursors
To: Denis Laxalde <denis.laxalde@dalibo.com>
Cc: psycopg@postgresql.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, 3 Feb 2021 at 17:16, Denis Laxalde <denis.laxalde@dalibo.com> wrote:

> Why do we need two 'await' (i.e. two IO operations) on conn.execute()
> and cur.fetchall() if 'cur' is a client-side cursor? (Back to my first
> point about where IO happen, this appears to depend on whether the
> connection has 'autocommit' or not...)

Around this point, one arguably not useful `await` is on
`connection.cursor()`. I wanted to put some flesh around server-side
cursors before making my mind around it. Now I have, as I am working
in a server-side cursor branch, and I don't think there are reasonable
cases where `connection.cursor()` might do I/O.

So, in the server-side branch, I've made the function non-async on
AsyncConnection too. This makes also context manager better to use, as
now you can do:

    async with aconn.cursor() as cur:
        # use it

whereas previously it would have taken an `async with await aconn.cursor()`.

I assume the change is welcome, but please let me know if this is not the case.

Cheers

-- Daniele