I like the way you can use Pydantic objects and load rows directly into those from v3. It makes things much easier overall. I made a single, simple class with a free methods that wrap queries and returns the rows as a list of objects instead. It’s also really fast because of the server side binding, I can do a very specific where clause and not have to use string interpolation dangerously for added speed; it just works faster now!
> PostgreSQL can represent a much wider range of dates and timestamps than Python. While Python dates are limited to the years between 1 and 9999 (represented by constants such as datetime.date.min and max), PostgreSQL dates extend to BC dates and past the year 10K. Furthermore PostgreSQL can also represent symbolic dates “infinity”, in both directions.<p>PostgreSQL can be used for many but not all sci fi stories. It's quite lacking about the past though [1] Even intervals are not so wide, only a plus minus 178 M years range?<p>[1] <a href="https://www.postgresql.org/docs/current/datatype-datetime.html" rel="nofollow noreferrer">https://www.postgresql.org/docs/current/datatype-datetime.ht...</a>
> If you need ClientCursor often, you can set the Connection.cursor_factory to have them created by default by Connection.cursor(). This way, Psycopg 3 will behave largely the same way of Psycopg 2.<p>These kind of changes are nice from a migration point of view, but eventually cause a significant amount of inconspicuous bugs. The framework now behaves differently in different applications.<p>And I actually don't like reading about potential client-side merging. I've been taught to only use parameterized queries, and not to write merging myself. I only trust the database to make the right call here.
It's great that the project has traction and the team still working in critical features.<p>I do not know if others have the same experience, but comparing Psycopg2/3 with SQL Alchemy I think the latter is way more robust and more developer friendly, but coming from a DBA background Psycopg sounds way simpler, even for the sake of writing pythonic code.