6 ms·

Differences from Psycopg2

• WirelessGigabit 3y ago
  > 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. 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. 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.
• ok_dad 3y ago
  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!
• MillionOClock 3y ago
  Nice to see Pyscopg 3 supports async/await, I don't think v2 did?
• andrewstuart 3y ago
  Interestingly, the native Python Postgres driver “Asyncpg” is faster than psycopg which is writhe in C.
  • Chiron1991 3y ago
    That's because psycopg adheres to the DBAPI standard (think of JDBC of the Python world). asyncpg deliberately ignores this standard for huge performance boosts.
  • FreakLegion 3y ago
    Asyncpg isn't pure Python, if that's what you mean by native. It's a heavy user of Python's C API, which is why PyPy can't run it. But yes, Asyncpg does tend to be quite a bit faster than Psycopg2 in most cases.
    • andrewstuart 3y ago
      OK I was wrong and stand corrected, asyncpg is not pure Python. asyncpg has these two C files and also uses Cython as far as I can see. https://github.com/MagicStack/asyncpg/blob/master/asyncpg/protocol/record/recordobj.c https://github.com/MagicStack/asyncpg/blob/master/asyncpg/pr... https://github.com/MagicStack/asyncpg/blob/master/asyncpg/protocol/record/recordobj.h https://github.com/MagicStack/asyncpg/blob/master/asyncpg/pr... If you are interested here is a post by the psycopg author about psycopg2 and 3 and performance versus asyncpg. https://www.varrazzo.com/blog/2020/05/19/a-trip-into-optimisation/ https://www.varrazzo.com/blog/2020/05/19/a-trip-into-optimis...
  • mjoin 3y ago
    what do you mean by 'native'? or, in other words, what makes psycopg non-native?
• pmontra 3y ago
  > 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. 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? [1] https://www.postgresql.org/docs/current/datatype-datetime.html https://www.postgresql.org/docs/current/datatype-datetime.ht...
• braza 3y ago
  It's great that the project has traction and the team still working in critical features. 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.
  • smashed 3y ago
    This is because they are not on the same level. If you are using SQL alchemy on a postgres db, you might be using psycopg without knowing it. Psycopg is the lower level lib that implements the PostgreSQL protocol. See https://docs.sqlalchemy.org/en/20/dialects/postgresql.html#dialect-postgresql https://docs.sqlalchemy.org/en/20/dialects/postgresql.html#d...