From: | Christophe Pettus <xof(at)thebuild(dot)com> |
---|---|
To: | Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net> |
Cc: | psycopg(at)lists(dot)postgresql(dot)org, psycopg(at)postgresql(dot)org |
Subject: | Re: about client-side cursors |
Date: | 2021-02-03 17:44:57 |
Message-ID: | D5AD2540-1414-4C13-9794-28282C8F5620@thebuild.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | psycopg |
> On Feb 3, 2021, at 09:41, Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)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(at)thebuild(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Daniele Varrazzo | 2021-02-03 17:47:53 | Re: about client-side cursors |
Previous Message | Daniele Varrazzo | 2021-02-03 17:44:33 | Re: about client-side cursors |