MIME-Version: 1.0
References: 
 <CA+mi_8Yc92bX3qhTqXq4LkGyn5VmQj6uRAcVebpqt398Tm4EJA@mail.gmail.com>
In-Reply-To: 
 <CA+mi_8Yc92bX3qhTqXq4LkGyn5VmQj6uRAcVebpqt398Tm4EJA@mail.gmail.com>
From: Vladimir Ryabtsev <greatvovan@gmail.com>
Date: Wed, 2 Dec 2020 06:49:33 -0800
Message-ID: 
 <CAMqTPqk0Ca1Ky1tGbmCLCwQEEmtfUbyVtds8J_MRykg=NPevmA@mail.gmail.com>
Subject: Re: Executing on the connection?
To: Daniele Varrazzo <daniele.varrazzo@gmail.com>
Cc: psycopg@postgresql.org
Content-Type: multipart/alternative; boundary="000000000000a2b7d505b57c5a2c"
Precedence: bulk

--000000000000a2b7d505b57c5a2c
Content-Type: text/plain; charset="UTF-8"

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 <daniele.varrazzo@gmail.com>
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
>
>
>

--000000000000a2b7d505b57c5a2c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I support this idea. Other drivers have such shortcuts (or=
 even lack cursor() equivalent at all).<div><br></div><div>I would even pre=
fer a shorter shortcut, like</div><div><br></div><div>conn.fetchone(query, =
params)</div><div><br></div><div>But it breaks parameter consistency at som=
e degree and bloats connection interface, so it&#39;s up to you.</div><div>=
<br></div><div>Vladimir</div></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Wed, 2 Dec 2020 at 03:20, Daniele Varrazzo=
 &lt;<a href=3D"mailto:daniele.varrazzo@gmail.com">daniele.varrazzo@gmail.c=
om</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
">Hello,<br>
<br>
if there is a thing that people approaching psycopg find confusing is<br>
the connection/cursor duality. The connection object as a wrapper for<br>
the database connection is clear to understand for anyone who has used<br>
psql. But the cursor as a means to give command is spurious: you can<br>
give commands but all the cursors are serialised, not parallelised, on<br>
the same connection, and it isn&#39;t useful for transactions either...<br>
<br>
The only unique thing a cursor has is to hold a result and consume it;<br>
for the rest it doesn&#39;t own neither the postgres session nor the<br>
transaction. But it gives them command. Weird.<br>
<br>
You are surely familiar with the psycopg2 usage pattern:<br>
<br>
=C2=A0 =C2=A0 conn =3D psycopg2.connect(dsn)<br>
=C2=A0 =C2=A0 cur =3D conn.cursor()<br>
=C2=A0 =C2=A0 cur.execute(query, params):<br>
=C2=A0 =C2=A0 for record in cur:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ... # do something<br>
<br>
The cursor() can take parameters, e.g. to create server-side &quot;named&qu=
ot;<br>
cursors, but most often people will use the standard client-side<br>
cursor, which is a lightweight object, little more than a wrapper for<br>
a PGresult.<br>
<br>
One little change I&#39;ve made to psycopg3 cursors is to make it return<br=
>
&quot;self&quot; on execute() (it currently returns None, so it&#39;s total=
ly<br>
unused). This allows chaining a fetch operation right after execute,<br>
so the pattern above can be reduced to:<br>
<br>
=C2=A0 =C2=A0 conn =3D psycopg3.connect(dsn)<br>
=C2=A0 =C2=A0 cur =3D conn.cursor()<br>
=C2=A0 =C2=A0 record =3D cur.execute(query, params).fetchone()<br>
=C2=A0 =C2=A0 # or<br>
=C2=A0 =C2=A0 for record in cur.execute(query, params):<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ... # do something<br>
<br>
And of course nastymess such as:<br>
<br>
=C2=A0 =C2=A0 conn.cursor().execute(query).fetchone()<br>
=C2=A0 =C2=A0 psycopg3.connect(dsn).cursor().execute(query).fetchone()<br>
<br>
But, taste.<br>
<br>
I&#39;m toying with the idea of adding a &#39;connection.execute(query,<br>
[params])&#39; methd, which would basically just create a cursor<br>
internally, query on it, and return it. No parameter could be passed<br>
to the cursor() call, so it could only create the most standard,<br>
client-side cursor (or whatever the default for the connection is, if<br>
there is some form of cursor_factory, which hasn&#39;t been implemented in<=
br>
psycopg3 yet). For anything more fancy, cursor() should be called<br>
explicitly.<br>
<br>
As a result people could use:<br>
<br>
=C2=A0 =C2=A0 conn =3D psycopg3.connect(dsn)<br>
=C2=A0 =C2=A0 record =3D conn.execute(query, params).fetchone()<br>
=C2=A0 =C2=A0 # or<br>
=C2=A0 =C2=A0 for record in conn.execute(query, params):<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ... # do something<br>
<br>
No other methods bloating the connection interface: no executemany(),<br>
copy(), callproc (actually there will be no callproc at all in<br>
psycopg3: postgres has no fast path for function call and too much<br>
semantics around stored procedure that a single callproc() couldn&#39;t<br>
cover).<br>
<br>
Being the cursor client-side, its close() doesn&#39;t actually do anythin<b=
r>
apart from making it unusable, so just disposing of it without calling<br>
close() is totally safe.<br>
<br>
Thoughts?<br>
<br>
Cheers!<br>
<br>
-- Daniele<br>
<br>
<br>
</blockquote></div>

--000000000000a2b7d505b57c5a2c--