Building a Django driver for Psycopg 3

I was wondering what the major changes between psycopg2 and psycopg3 were. Found a post from the maintainer here: <a href="https:&#x2F;&#x2F;www.varrazzo.com&#x2F;blog&#x2F;2020&#x2F;03&#x2F;06&#x2F;thinking-psycopg3&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.varrazzo.com&#x2F;blog&#x2F;2020&#x2F;03&#x2F;06&#x2F;thinking-psycopg3&#x2F;</a><p>Main takeaways:<p>- Asyncio from the ground up<p>- Uses PQexecParams to do database-side escaping and interpolation<p>- ContextManager and transaction api improvements for<p>- Python only fallback if the C extension fails to build

Just a huge thank you to Daniele for developing and maintaining psycopg! The article shows the level of professionalism and care that goes into this project. Using Django to test implementation is a genius idea. I can&#x27;t wait to try the new version in a few of my projects, the changes (especially server-side parameters binding) sound great.

A somebody who first started using DB code from Perl, and later learned Python, I always wondered by Python doesn&#x27;t have a general database interface like DBI in Perl.<p>In Perl, all the database specific modules have a DBI backend, and all the higher-level modules (django-like frameworks, for example) rely on DBI.<p>In Python, SQLAlchemy has its own psycopg and cmysql integrations, and does django, and likely several other frameworks.<p>(Java has a similar standard, with JDBC, I believe; though I have never used it, so I might be misunderstanding something here).

Casually building a django db backend as an acceptance test. Nice work and great write up!<p>I had déjà vu reading the section on bind parameters in aggregate queries. The oracle backend had a similar issue that was fixed&#x2F;hacked by comparing values and grouping them into named parameters. <a href="https:&#x2F;&#x2F;code.djangoproject.com&#x2F;ticket&#x2F;27632" rel="nofollow">https:&#x2F;&#x2F;code.djangoproject.com&#x2F;ticket&#x2F;27632</a>

The example syntax for connection handling is perfect. The footgun of not releasing the connection (especially from pools at the end of the with) is real. And the concepts are different (block of transactions vs normal with file xxx. )<p><pre><code> with connect(DSN) as conn: with conn.transaction(): do_something() with conn.transaction(): do_something_nested() with conn.transaction() as tx: do_something_else() # we were just testing and we don&#x27;t really want to do this tx.rollback() # and here the connection is closed </code></pre> Any chance of pushing some changes up into the postgresql side? I&#x27;m thinking of a block of trx with params separate? Didn&#x27;t look at it at all.

Really great to see more than one viable async database library aside from asyncpg.<p>Thank you!!

Thanks for your hard work in making the transition from psycopg2 to psycopg3 as simple and painless as possible, Daniele!