| 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 14:44:07 |
| Message-ID: | BAB9FCFC-96F6-48E2-98EA-FF851AA6C884@thebuild.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | psycopg |
> On Feb 4, 2021, at 03:16, Denis Laxalde <denis(dot)laxalde(at)dalibo(dot)com> wrote:
> But, unless I missed it, the PEP does not state how to implement query
> execution and result fetch operations if the database does not need a
> cursor.
First, any change like this would have to maintain their current API essentially forever, unless psycopg3 represents a completely incompatible break with the psycopg2 interface. There is an enormous body of code out there that uses the current cursor() interface for client-side cursors.
Second, it would be very unwise to make guarantees about when these operations interact with the database. I think that any client application should expect that both cursor.execute() and cursor.fetchone()/.fetchall() are asynchronous operations, and code appropriately.
--
-- Christophe Pettus
xof(at)thebuild(dot)com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Denis Laxalde | 2021-02-04 15:02:03 | Re: about client-side cursors |
| Previous Message | Denis Laxalde | 2021-02-04 11:16:47 | Re: about client-side cursors |