public inbox for [email protected]
help / color / mirror / Atom feedFrom: Christophe Pettus <[email protected]>
To: Denis Laxalde <[email protected]>
Cc: Daniele Varrazzo <[email protected]>
Cc: [email protected]
Subject: Re: about client-side cursors
Date: Thu, 4 Feb 2021 08:44:31 -0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<CA+mi_8a1ery2xvb+AdxMtVXydOdGC7wRMnfXNAvk8v73HsLFyw@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
> On Feb 4, 2021, at 08:38, Denis Laxalde <[email protected]> wrote:
> 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.)
No, this is separate from prepared statements or the extended protocol. You can do single-row returns with either basic or extended protocol.
It's unfortunate that cursor as become overloaded, but I think that's something we just have to accept at this point. It sounds like the real issue is that it would be convenient to have a single async function that does the semantic equivalent of:
curs = connection.cursor()
curs.execute(query, *parameters)
for row in curs.fetchall():
yield row
curs.close()
--
-- Christophe Pettus
[email protected]
view thread (22+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: about client-side cursors
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox