MIME-Version: 1.0
References: <20210203161548.vkhu3qkpvmgvyhik@dalibo.com>
 <CA+mi_8a1ery2xvb+AdxMtVXydOdGC7wRMnfXNAvk8v73HsLFyw@mail.gmail.com>
 <YB0SwZapH8LujF6O@hermes.hilbert.loc>
In-Reply-To: <YB0SwZapH8LujF6O@hermes.hilbert.loc>
From: Daniele Varrazzo <daniele.varrazzo@gmail.com>
Date: Fri, 5 Feb 2021 11:40:31 +0100
Message-ID: 
 <CA+mi_8YoLnH1XgXjKoGCaYY2qLk2XjVexHe1q-j4KxjACF9y2A@mail.gmail.com>
Subject: Re: about client-side cursors
To: psycopg@lists.postgresql.org, psycopg@postgresql.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, 5 Feb 2021 at 10:41, Karsten Hilbert <Karsten.Hilbert@gmx.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