Re: about client-side cursors

On Fri, 5 Feb 2021 at 10:41, Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net> wrote:

> Given that people interested in using conn.execute() don't
> seem to want to concern themselves with cursors at all (until
> there's an explicit need, at which point they would seem to
> want a server-side cursor, and use conn.cursor()), and the
> fact that conn.execute() is outside the DB-API anyway, I
> wonder whether this
>
> class connection:
> def execute(self, query, vars)
> cur = self.cursor()
> cur.execute(query, vars)
> return cur.fetchall()
>
> makes even more sense ?
>
> Perhaps even reconsider naming it "execute".

If it didn't return a cursor, it would make sense to reconsider
calling it execute(). As it is now it returns the same that cursor
returns, it's pretty much just a contraption of a chain of methods,
hence the same name.

If you return just the fetchall list you lose access to results
metadata (description), nextset, and someone will come asking "can I
have executefetchone() please" the next minute :)

I'll play a bit more with it in the test suite (which is currently the
main body of code using psycopg3) and think about it.

-- Daniele