Re: about client-side cursors

> 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