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 15:02:03 |
Message-ID: | 20210204150203.iuophq3yx7nzpfzo@dalibo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | psycopg |
Christophe Pettus a écrit :
> > 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.
Sure, that's a valid point. But maintaining this backwards compatibility
does not mean we can't hide the details and advertise a cleaner API for
newcomers or people willing to migrate.
> 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.
If "cursor" is a real database cursor, I agree.
From | Date | Subject | |
---|---|---|---|
Next Message | Christophe Pettus | 2021-02-04 15:17:37 | Re: about client-side cursors |
Previous Message | Christophe Pettus | 2021-02-04 14:44:07 | Re: about client-side cursors |