public inbox for [email protected]  

help / color / mirror / Atom feed

From: Vladimir Ryabtsev <[email protected]>
To: Daniele Varrazzo <[email protected]>
Cc: [email protected]
Subject: Re: Executing on the connection?
Date: Wed, 2 Dec 2020 06:49:33 -0800
Message-ID: <CAMqTPqk0Ca1Ky1tGbmCLCwQEEmtfUbyVtds8J_MRykg=NPevmA@mail.gmail.com> (raw)
In-Reply-To: <CA+mi_8Yc92bX3qhTqXq4LkGyn5VmQj6uRAcVebpqt398Tm4EJA@mail.gmail.com>
References: <CA+mi_8Yc92bX3qhTqXq4LkGyn5VmQj6uRAcVebpqt398Tm4EJA@mail.gmail.com>

I support this idea. Other drivers have such shortcuts (or even lack
cursor() equivalent at all).

I would even prefer a shorter shortcut, like

conn.fetchone(query, params)

But it breaks parameter consistency at some degree and bloats connection
interface, so it's up to you.

Vladimir

On Wed, 2 Dec 2020 at 03:20, Daniele Varrazzo <[email protected]>
wrote:

> Hello,
>
> if there is a thing that people approaching psycopg find confusing is
> the connection/cursor duality. The connection object as a wrapper for
> the database connection is clear to understand for anyone who has used
> psql. But the cursor as a means to give command is spurious: you can
> give commands but all the cursors are serialised, not parallelised, on
> the same connection, and it isn't useful for transactions either...
>
> The only unique thing a cursor has is to hold a result and consume it;
> for the rest it doesn't own neither the postgres session nor the
> transaction. But it gives them command. Weird.
>
> You are surely familiar with the psycopg2 usage pattern:
>
>     conn = psycopg2.connect(dsn)
>     cur = conn.cursor()
>     cur.execute(query, params):
>     for record in cur:
>         ... # do something
>
> The cursor() can take parameters, e.g. to create server-side "named"
> cursors, but most often people will use the standard client-side
> cursor, which is a lightweight object, little more than a wrapper for
> a PGresult.
>
> 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
>
> And of course nastymess such as:
>
>     conn.cursor().execute(query).fetchone()
>     psycopg3.connect(dsn).cursor().execute(query).fetchone()
>
> But, taste.
>
> 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?
>
> Cheers!
>
> -- Daniele
>
>
>

view thread (13+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: Executing on the connection?
  In-Reply-To: <CAMqTPqk0Ca1Ky1tGbmCLCwQEEmtfUbyVtds8J_MRykg=NPevmA@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox