Elvis Pranskevichus

> Should I rely on a temporary table and then upserting into the physical tables from that temporary table? This would be the best alternative approach.

Exposing the results of `CommandComplete` in `executemany()` context seems rather complicated. Why not use another temp table to store the number of affected rows?

Something like: ``` CREATE TEMP TABLE merge_ops(rowcount int); ``` Then, ```python conn.executemany( ''' WITH ins AS ( RETURNING *) INSERT INTO merge_ops(rowcount) (SELECT count(*) FROM ins) ''' ) ``` Then,...

We used to have a guard for `UNLISTEN`, which was expensive and it was deemed that supporting old unpatched versions of Postgres is not worth the perf hit. See #648...

The `UNLISTEN` fix was backported to PostgreSQL 9.4.21, 9.5.16, 9.6.12, 10.7, and 11.2. The best course of action is to update to the latest Postgres point release.

There is, unfortunately, no way to detect a master switch without polling. I wrote a [patch](http://postgr.es/m/[email protected]) to add that feature a while ago, but that effort got sidetracked. I plan...

> Thank you for response! Unfortunately link leading to the patch returns 404. Fixed. > You implemented postgresql patch, that allows to detect master switch without it, right? Yes. That...

You can check on `acquire()`, sure, it's just going to be a tad more complicated and would require subclassing the `Pool`.

It didn't make it into 12, but there's an active discussion on including the functionality in 13.

> have to implement support for target_session_attrs myself I'd be happy to accept a PR to add support for this to asyncpg.