Elvis Pranskevichus

Here's the relevant part of the documentation: https://magicstack.github.io/asyncpg/current/api/index.html#cursors. Iterable cursors are cursors that are used directly as iterator rather than an object that calling `fetch()`, so ``` # cursor with...

There's already a way to override connection behavior: make a subclass and pass it in as `connection_class` argument to `connect()`.

Server capabilities aren't meant to be an API and overriding the detection is a bad idea, because new releases might add more caps for newer Postgres versions or alternative implementations...

When submitting an issue, please provide the information asked for in the issue template. Specifically, which version of PostgreSQL are you using?

We don't really support PostgreSQL versions that old. In this particular case, `pg_listening_channels()` is a system function introduced in PostgreSQL 9.0. It seems that earlier versions relied on the `pg_listener`...

Oh, `cluster.py` is private to asyncpg, ideally you shouldn't rely on it directly as an API. That said, a better fix here would likely be to run `_test_connection` in a...

This is one of the unfortunate aspects of Python asyncio. There is no way to surface exceptions in background tasks (which `_cancel` is) other than logging them.

asyncpg has no way of knowing that the schema has changed under it, so you are supposed to deliver that notification to your webserver and call [reload_schema_state](https://magicstack.github.io/asyncpg/current/api/index.html#asyncpg.connection.Connection.reload_schema_state) explicitly.

Are you able to provide a traceback?

Unfortunately, the `datatype_mismatch` SQL error is not specific enough. In some cases it indicates outdated prepared statement query plans, which would be safe to retry automatically, but in other cases...