Re: Executing on the connection?

On Wed, 2 Dec 2020 at 12:20, Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>
wrote:

> One little change I've made to psycopg3 cursors is to make it return
> "self" on execute() (it currently returns None, so it's totally
> unused). This allows chaining a fetch operation right after execute,
> so the pattern above can be reduced to:
>
> conn = psycopg3.connect(dsn)
> cur = conn.cursor()
> record = cur.execute(query, params).fetchone()
> # or
> for record in cur.execute(query, params):
> ... # do something

> I'm toying with the idea of adding a 'connection.execute(query,
> [params])' methd, which would basically just create a cursor
> internally, query on it, and return it. No parameter could be passed
> to the cursor() call, so it could only create the most standard,
> client-side cursor (or whatever the default for the connection is, if
> there is some form of cursor_factory, which hasn't been implemented in
> psycopg3 yet). For anything more fancy, cursor() should be called
> explicitly.
>
> As a result people could use:
>
> conn = psycopg3.connect(dsn)
> record = conn.execute(query, params).fetchone()
> # or
> for record in conn.execute(query, params):
> ... # do something
>
> No other methods bloating the connection interface: no executemany(),
> copy(), callproc (actually there will be no callproc at all in
> psycopg3: postgres has no fast path for function call and too much
> semantics around stored procedure that a single callproc() couldn't
> cover).
>
> Being the cursor client-side, its close() doesn't actually do anythin
> apart from making it unusable, so just disposing of it without calling
> close() is totally safe.
>
> Thoughts?

I like it a lot!

Ciao.
Marco.