| From: | Christophe Pettus <xof(at)thebuild(dot)com> |
|---|---|
| To: | Denis Laxalde <denis(dot)laxalde(at)dalibo(dot)com> |
| Cc: | Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>, psycopg(at)postgresql(dot)org |
| Subject: | Re: about client-side cursors |
| Date: | 2021-02-04 15:17:37 |
| Message-ID: | 3BA6B9FE-9A00-4F04-9C0B-263EE4301985@thebuild.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | psycopg |
> On Feb 4, 2021, at 07:02, Denis Laxalde <denis(dot)laxalde(at)dalibo(dot)com> wrote:
>
> If "cursor" is a real database cursor, I agree.
But it's not just CURSORs that have this behavior. libpq allows the client to the send the query, and then make separate requests for each row, even without a database cursor; this maps almost exactly to .execute() and .fetchone(). It doesn't seem a good idea to guarantee forever that .execute() will *never* do I/O without a database-side cursor.
Having a single convenience method on the connection object that does the equivalent of a .execute() and a .fetchall() might be useful, though.
--
-- Christophe Pettus
xof(at)thebuild(dot)com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daniele Varrazzo | 2021-02-04 15:24:22 | Re: about client-side cursors |
| Previous Message | Denis Laxalde | 2021-02-04 15:02:03 | Re: about client-side cursors |