[parhamn]

I was wondering what the major changes between psycopg2 and psycopg3 were. Found a post from the maintainer here: https://www.varrazzo.com/blog/2020/03/06/thinking-psycopg3/

Main takeaways:

- Asyncio from the ground up

- Uses PQexecParams to do database-side escaping and interpolation

- ContextManager and transaction api improvements for

- Python only fallback if the C extension fails to build

[Waterluvian]

That last one is great if it’s hidden behind a flag and some loud messages saying “failed to build, consider using —-python-only with performance limitation.”

Otherwise it’s going to be a source of mysterious performance issues with a single error message hidden somewhere in your CI or other logs.

[acdha]

I'm a bit mixed on a flag because C library dependencies are a fair support burden and an awful lot of people do not have workloads where a pure Python implementation is a significant performance issue because it's lost in the actual work done by the database.

I'd agree with something like a warning on first load or maybe something like an optional package so you could pin `psycopg3[cext]` if you want to guarantee the extension installed.

[dvarrazzo]

There is a mechanism to ensure that there is no unexpected regression. Exposing the PSYCOPG_IMPL env var a program can make sure to obtain a specific implementation and import fails if it's not available. https://www.psycopg.org/psycopg3/docs/api/pq.html

[odiroot]

> - Asyncio from the ground up

> - Python only fallback if the C extension fails to build

These two are really big! The former, for first-party async support, making it much easier to use with async frameworks.

The latter would make it much easier to ship in containers. I assume it's still better use the C version, for performance reasons.

[whoknowswhat11]

YES to this last!! Musl cross deploy can be annoying otherwise - any tips on building Alpine Linux ?