| From: | Denis Laxalde <denis(dot)laxalde(at)dalibo(dot)com> |
|---|---|
| To: | Christophe Pettus <xof(at)thebuild(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 16:38:52 |
| Message-ID: | 20210204163852.5mwvddtr74aw6wrh@dalibo.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | psycopg |
Christophe Pettus a écrit :
> 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().
Is this related to prepared statements in the extended query protocol?
(Then, I'd argue that both preparation and execution steps would involve
IO. But if it's not a cursor, we should use a different name, as
postgresql doc does.)
> It doesn't seem a good idea to guarantee
> forever that .execute() will *never* do I/O without a database-side
> cursor.
Currently, it seems to me that .execute() always do IO with or without a
database cursor.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christophe Pettus | 2021-02-04 16:44:31 | Re: about client-side cursors |
| Previous Message | Daniele Varrazzo | 2021-02-04 15:24:22 | Re: about client-side cursors |