Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kkSOm-0003t4-SB for psycopg@arkaria.postgresql.org; Wed, 02 Dec 2020 13:42:25 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kkSOl-0008Iz-QC for psycopg@arkaria.postgresql.org; Wed, 02 Dec 2020 13:42:23 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kkSOl-0008Hu-Ik for psycopg@lists.postgresql.org; Wed, 02 Dec 2020 13:42:23 +0000 Received: from mail-il1-x129.google.com ([2607:f8b0:4864:20::129]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kkSOi-0001SF-4b for psycopg@postgresql.org; Wed, 02 Dec 2020 13:42:22 +0000 Received: by mail-il1-x129.google.com with SMTP id f5so1548486ilj.9 for ; Wed, 02 Dec 2020 05:42:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JSTfhMaJSwsGTVxN0296qkKhk5n6kmo5g7f7WlYpLFM=; b=sVc7ynSAXYYHflupLUXQ2t8CHxkzkbjAqqkkLjtFFOYAwra6WZAqHYE3VcJZu92hoW IY1VIQUfp3WezWYSm0UydXq/9SaHlA2yrBtYq6ceH3w9wEZOuOVkrpIGQAEim2sAy5i5 Gscn+VkQKIEq81CT3Ql2LMEY7ao98DK4OfUl4NxHnd49k2bk3eIfO0xBBfU4XShOQHIc 5qspQ46ou4z4uj16KApcgLUA0C7t8dc6fV2GO9RlonM8MR4FSqFZXnC5tiy1NpEYs/O8 1feZaDXK8fRo6kvM1DZ1mSQ8eOqivHFXwsS6fC7JRd0Z/jwkY2viIBJZFMWX3oUjiOSI M8vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JSTfhMaJSwsGTVxN0296qkKhk5n6kmo5g7f7WlYpLFM=; b=I6YTYPVnelHwKnqsMbhwKFpIDuJ9HxxA1GUBnYt/bQAktjw1tm0CBwsF9RYywthJZP 2OUcTXHHSTu1yuW/JwtJjjZNhW9Ymr7Vi68FqQo9p9Z2lkOQBUCSRxdf3MZTUMlAuoU4 B9V592eTv4vxy/R9Uo43+W//DRtr5DVegCGuBU7Lw/6ayV5oSdEED8rWv4Qy/2/r+/6d JtVG5u4/c/ufpE7Wvz9y5uGaQTtM9rVX814qG/C6uw289L3XKhBr6iDRq1pvRLmjh2nG ZWrXwey/OvBnXGQBa31pKT7dYMoOoT/f3fTCjoPfx5Qnmqbhempyb5QauyqIRwSTHnlL /UYA== X-Gm-Message-State: AOAM5318C0pj6P958A8JNEkFjr3//ZkFc2D+xZnIBpIKlgy6+zeE27Y+ lYndhipjWO9zsLjTp17dbzAao6xVrGKDkFSchAo= X-Google-Smtp-Source: ABdhPJxLuJgiWMcnHgZ+HaFwlL0Vi/FEfB3kf3gxf0kQNUU7x2ICh8eoPQkLNU7E9/ScOLG7aoNXPcM7JbvdCzIwB5k= X-Received: by 2002:a92:a043:: with SMTP id b3mr2399398ilm.272.1606916539354; Wed, 02 Dec 2020 05:42:19 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Marco Beri Date: Wed, 2 Dec 2020 14:41:43 +0100 Message-ID: Subject: Re: Executing on the connection? To: Daniele Varrazzo Cc: psycopg@postgresql.org Content-Type: multipart/alternative; boundary="00000000000083172e05b57b69a6" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --00000000000083172e05b57b69a6 Content-Type: text/plain; charset="UTF-8" On Wed, 2 Dec 2020 at 12:20, Daniele Varrazzo 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. --00000000000083172e05b57b69a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, 2 Dec 2020 at 12:20, Daniele Varrazzo <daniele.varrazzo@gmail.com&= gt; wrote:
One little change I've made to psyco= pg3 cursors is to make it return
"self" on execute() (it currently returns None, so it's total= ly
unused). This allows chaining a fetch operation right after execute,
so the pattern above can be reduced to:

=C2=A0 =C2=A0 conn =3D psycopg3.connect(dsn)
=C2=A0 =C2=A0 cur =3D conn.cursor()
=C2=A0 =C2=A0 record =3D cur.execute(query, params).fetchone()
=C2=A0 =C2=A0 # or
=C2=A0 =C2=A0 for record in cur.execute(query, params):
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ... # do something=C2=A0
=C2=A0

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<= br> psycopg3 yet). For anything more fancy, cursor() should be called
explicitly.

As a result people could use:

=C2=A0 =C2=A0 conn =3D psycopg3.connect(dsn)
=C2=A0 =C2=A0 record =3D conn.execute(query, params).fetchone()
=C2=A0 =C2=A0 # or
=C2=A0 =C2=A0 for record in conn.execute(query, params):
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ... # 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.
--00000000000083172e05b57b69a6--