Re: about client-side cursors

> On Feb 4, 2021, at 08:38, Denis Laxalde <denis(dot)laxalde(at)dalibo(dot)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 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
xof(at)thebuild(dot)com