> On Feb 4, 2021, at 08:38, Denis Laxalde <denis.laxalde@dalibo.com> 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
basicor extended protocol.
It's unfortunate that cursor as become overloaded, but I think that's something we just have to accept at this point.
Itsounds like the real issue is that it would be convenient to have a single async function that does the semantic
equivalentof:
curs = connection.cursor()
curs.execute(query, *parameters)
for row in curs.fetchall():
yield row
curs.close()
--
-- Christophe Pettus
xof@thebuild.com