about client-side cursors
От | Denis Laxalde |
---|---|
Тема | about client-side cursors |
Дата | |
Msg-id | 20210203161548.vkhu3qkpvmgvyhik@dalibo.com обсуждение исходный текст |
Ответы |
Re: about client-side cursors
Re: about client-side cursors Re: about client-side cursors |
Список | psycopg |
Hi, I'd like to discuss about the concept of client-side cursor as defined in psycopg. This is a concept I've always been quite uncomfortable with; I'll try to explain why. First, from a practical point of view: cur = connection.cursor() cur.execute(...) result = cur.fetchxxx() This typical pattern seems awkward to me. Where do IO operations actually take place? (on execute()? on fetch()? on both?) Then, and besides the terminology, the fact that named cursors are very different from client-side cursors while being constructed by the same API is confusing. I understand that this may come from the DB-API: https://www.python.org/dev/peps/pep-0249/#cursor-objects > [Cursor] objects represent a database cursor. [...] But this does not seem quite right to me since a client-side cursor is actually not a PostgreSQL cursor. (The documention on psycopg2 is clear on the difference, though.) In asyncio context, while playing around with psycopg3, the situation is even worse because of the additional async/await keywords; for instance: conn = await psycopg3.AsyncConnection.connect() async with conn: cur = await conn.execute("SELECT * FROM test") r = await cur.fetchall() Why do we need two 'await' (i.e. two IO operations) on conn.execute() and cur.fetchall() if 'cur' is a client-side cursor? (Back to my first point about where IO happen, this appears to depend on whether the connection has 'autocommit' or not...) All in all, my main point is: (why) do we need client-side cursors? Thanks, Denis
В списке psycopg по дате отправления: