Re: improving async support in psycopg

On 28/03/10 04:10, Daniele Varrazzo wrote:
> On Sun, Mar 28, 2010 at 2:35 AM, Daniele Varrazzo
> <[email protected]>  wrote:
> OTOH, looking at the pqpath.c, many functions call PQexec (via
> pq_execute_command_locked) and set the connection state according to
> its result (begin, commit and rollback). reset() instead executes a
> sequence of 2 or 3 operations (something similar to what connect()
> does). If those methods were to be made async, it seems to me that the
> knowledge about "how to block" should be available at C level.

Yeah, there are places where psycopg2 issues queries behind your back :( 
That's why I said that a user of the async features would probably have 
to set the transaction isolation level to autocommit and issue his own 
BEGINs and COMMITs from a Cursor.execute() instead.

I think that the way to fix it would be to use a similar trick to the 
one in async connecting: when you execute something for the first time 
in a cursor, issue a BEGIN behind the user's back, make him poll the 
cursor and then when the BEGIN finishes, issue the real query and 
continue polling. This way it's more or less trasparent. COMMIT, 
possibly ROLLBACK and things like encoding setting would need to be 
handled this way as well... But since you can manage transactions 
yourself, I didn't look into implementing that behaviour yet.

Cheers,
Jan