On Fri, 5 Feb 2021 at 10:41, Karsten Hilbert <[email protected]> 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
