> On Feb 4, 2021, at 09:21, Denis Laxalde wrote:
>
> Well, maybe I'm missing something... In the examples above, (written
> down explicitly to understand where IO happens), if I shut down postgres
> between 'await conn.execute()' and 'await cur.fetchall()', the first
> example breaks but the s
Daniele Varrazzo a écrit :
> On Thu, 4 Feb 2021 at 12:16, Denis Laxalde wrote:
>
> > Daniele Varrazzo a écrit :
> > > This is understandable, so much that in psycopg3 I've added
> > > conn.execute, which is implemented as:
>
> > I am aware of that and that's indeed a nice addition. As I mentione
On Thu, 4 Feb 2021 at 12:16, Denis Laxalde wrote:
> Daniele Varrazzo a écrit :
> Then, having fetch*() methods on client-side cursors is also misleading
> because nothing gets fetched actually, it's just result unpacking.
Arguably the naming is not correct, and they have been called that way
to
Hello,
(message is getting so long as to require titles, so here they are)
# Latest adaptation woes
I have finally broken the adaptation model where a Python class gets
adapted to a Postgres type. The model is what psycopg2 is based on but
for psycopg3 it was proving unsatisfactory.
The proble
> On Feb 4, 2021, at 08:38, Denis Laxalde wrote:
> 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.)
No, th
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 s
On Thu, 4 Feb 2021 at 16:17, Christophe Pettus wrote:
> Having a single convenience method on the connection object that does the
> equivalent of a .execute() and a .fetchall() might be useful, though.
You can already do it (in psycopg3):
for record in conn.execute("query"):
# do s
> On Feb 4, 2021, at 07:02, Denis Laxalde 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 alm
Christophe Pettus a écrit :
> > On Feb 4, 2021, at 03:16, Denis Laxalde 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 th
> On Feb 4, 2021, at 03:16, Denis Laxalde 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,
Hi,
Daniele Varrazzo a écrit :
> On Wed, 3 Feb 2021 at 17:16, Denis Laxalde wrote:
>
> > I'd like to discuss about the concept of client-side cursor as defined
> > in psycopg.
>
> Welcome Denis!
>
>
> > This is a concept I've always been quite uncomfortable with;
> > I'll try to explain why.
11 matches
Mail list logo
