Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
Subject: Re: about client-side cursors
From: Christophe Pettus <xof@thebuild.com>
In-Reply-To: <YBrgZHfu4rBNFDLk@hermes.hilbert.loc>
Date: Wed, 3 Feb 2021 09:44:57 -0800
Cc: psycopg@lists.postgresql.org,
 psycopg@postgresql.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <D5AD2540-1414-4C13-9794-28282C8F5620@thebuild.com>
References: <20210203161548.vkhu3qkpvmgvyhik@dalibo.com>
 <8E9B3B86-4691-4F09-B853-EA1F4CB86CF4@thebuild.com>
 <YBrgZHfu4rBNFDLk@hermes.hilbert.loc>
To: Karsten Hilbert <Karsten.Hilbert@gmx.net>
Precedence: bulk


> On Feb 3, 2021, at 09:41, Karsten Hilbert <Karsten.Hilbert@gmx.net> =
wrote:
> Perhaps client-side cursors were invented to make it possible
> to code to the same API regardless of whether real
> (server-side) cursors are used or not ?

That's definitely part of it.

The name "cursor" for the client-side object is a bit unfortunate, but =
we need *something* there.  The operations are:

1. Send query to server and execute it.
2. Retrieve results from server.

Those are both asynchronous operations, and we need something to =
encapsulate the state to pass from #1 to #2.  You could just have the =
connection object do that, but then we're declaring forever that we =
can't run two queries at the same time on the same connection, and that =
seems unwise.

--
-- Christophe Pettus
   xof@thebuild.com