Am Wed, Feb 03, 2021 at 06:44:33PM +0100 schrieb Daniele Varrazzo:
> Yes, that's correct: the name comes from the dbapi. The dbapi cursor
> does two different things indeed: it runs queries and manages results.
> I understand that the overlap is sort of weird and everyone who has
> said "psycopg sucks: let me write my own driver" have used the mental
> model - much more familiar - of "I ask a query to a connection which
> gives me a result". So usually what is created is something which can
> be used as:
>
> result = conn.execute(query, vars)
> for record in result:
> ...
>
> This is understandable, so much that in psycopg3 I've added
> conn.execute, which is implemented as:
>
> def execute(self, query, vars)
> cur = self.cursor()
> cur.execute(query, vars)
> return cur
>
> and allow you to use the cursor only to iterate on the data returned,
> ignoring the execute*() methods.
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".
> The Server versions have I/O done on fetch*() and on close(). So the
> first three objects might have non-async fetch(). I was preferring to
> give all them an uniform interface
+1
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B