Closed interrogator closed 1 year ago
But this setting does not stop them from being used entirely
Prepared statements are an integral part of PostgreSQL extended query protocol which asyncpg uses. That said, I'm not sure why you would want to disable those as that flow should work just fine with pgbouncer. Can you give a more concrete example of a problem you're seeing?
I have some SQL strings with multiple commands (i.e.
INSERT a; INSERT B;
), which cannot be made into prepared statements.When using SQLAlchemy, it seems like
asyncpg
is always called in such a way that prepared statements are always generated.There is an issue on a related subject, where the
prepared_statement_cache_size
option can be used to avoid cacheing the statements. But this setting does not stop them from being used entirely. Most of the above issue is only about changing the way such statements are named/identified/stored. Even with this set to0
, the statements are still created and called.The only way I can find to get around this problem is to call asyncpg more directly:
Is there any nicer solution for this? I'd like to skip
get_raw_connection
,.cursor()
and_connection
, and use SQLAlchemy more as intended, but without generating any prepared statements.Also, a somewhat related question, does SQLAlchemy provide a way of accessing asyncpg's
copy_to_table
other than the above? I can't find much documentation about this, nor anything specific toCOPY
in the source.