From: | Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com> |
---|---|
To: | Denis Laxalde <denis(dot)laxalde(at)dalibo(dot)com> |
Cc: | psycopg(at)postgresql(dot)org |
Subject: | Re: about client-side cursors |
Date: | 2021-02-10 12:43:39 |
Message-ID: | CA+mi_8a4A9-fu39sLzvGbeqF9odLBNuyORfMc5K4yv=XgZQjsA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | psycopg |
On Wed, 3 Feb 2021 at 17:16, Denis Laxalde <denis(dot)laxalde(at)dalibo(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Denis Laxalde | 2021-02-10 14:46:54 | Re: about client-side cursors |
Previous Message | Daniel Fortunov | 2021-02-08 22:38:10 | Re: Latest developments in psycopg3 |