public inbox for [email protected]  

help / color / mirror / Atom feed

From: Christophe Pettus <[email protected]>
To: Denis Laxalde <[email protected]>
Cc: Daniele Varrazzo <[email protected]>
Cc: [email protected]
Subject: Re: about client-side cursors
Date: Thu, 4 Feb 2021 09:31:22 -0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<CA+mi_8a1ery2xvb+AdxMtVXydOdGC7wRMnfXNAvk8v73HsLFyw@mail.gmail.com>
	<[email protected]>
	<CA+mi_8ZhJGgZ46POUn2Bujb1e9guiampac0x+S54x05dSOXUJQ@mail.gmail.com>
	<[email protected]>



> On Feb 4, 2021, at 09:21, Denis Laxalde <[email protected]> wrote:
> 
> Well, maybe I'm missing something... In the examples above, (written
> down explicitly to understand where IO happens), if I shut down postgres
> between 'await conn.execute()' and 'await cur.fetchall()', the first
> example breaks but the second doesn't. Perhaps the autocommit mention
> was misleading; it's enough to insert 'await conn.commit()' before
> 'await cur.fetchall()' to reproduce. So (and again, unless I'm missing
> something), if this is not "by design", maybe this is bug?

You're relying on private knowledge, not an API guarantee, as to "where I/O happens" here.  Like any expectation based on private knowledge, you can get tripped up by that.

We shouldn't write into the API contract that either cursor.execute() or cursor.fetch*() are guaranteed not to fail with an I/O error.  Any time you interact with the cursor object, that can be assumed to be an asynchronous operation that can fail due to the remote server not being available.  Knowing that, you can reasonably code defensively no matter what.

Adding those explicit guarantees about I/O to the API hugely limits underlying implementation changes in the future, for as far as I can tell no real gain.

If it comes down to "cursor isn't a good name for this class," that's probably true, but we're a decade past making that decision.

> As far as the async interface is concerned, I think there is no adoption
> issue because there's no precedent use from psycopg2. So we could
> expose two API: cursorless querying ('await conn.execute()') and have a
> single server-side cursor class.

Right now, switching from using just a client-side cursor object to server-side cursor preserves largely preserves the API.  I think that's a valuable feature that's worth retaining.

--
-- Christophe Pettus
   [email protected]

view thread (22+ 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], [email protected]
  Subject: Re: about client-side cursors
  In-Reply-To: <[email protected]>

* 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