Re: about client-side cursors - Mailing list psycopg

From Karsten Hilbert
Subject Re: about client-side cursors
Date
Msg-id YB0h2l9Slk4TKUsW@hermes.hilbert.loc
Whole thread Raw
In response to Re: about client-side cursors  (Daniele Varrazzo <daniele.varrazzo@gmail.com>)
List psycopg
Am Fri, Feb 05, 2021 at 11:40:31AM +0100 schrieb Daniele Varrazzo:

> >         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 :)

Yeah, I know. Therefore I thought maybe "conn.run_query()" or
some such because execute() is already loaded with meaning.

If one wants access to what a cursor provides, as defined by
the DB-API, one should _use_ a cursor, as per DB-API :-)

Or, perhaps, it returns a generator over the fetchall()
results list ?

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B



psycopg by date:

Previous
From: Daniele Varrazzo
Date:
Subject: Re: about client-side cursors
Next
From: Daniele Varrazzo
Date:
Subject: libpq pipeline/batch mode