Right - and there does have to be some kind of non native transform mixed in? At least with shell scripting this kind of thing has bitten me frequently.
Author here of the PostgreSQL raw queries feature mentioned in the release notes, which allows users to use PostgreSQL's native placeholders ($1, $2, etc.) instead of the standard %s placeholder [1].
from psycopg import connect, RawCursor
with connect(dsn, cursor_factory=RawCursor) as conn:
with conn.cursor() as cur:
cur.execute("SELECT $1, $2", [1, "Hello"])
assert cur.fetchone() == (1, "Hello")
The release notes highlight several interesting advantages I hadn't considered. However, they don't mention the primary motivation behind my contribution, so I thought I'd share it here:
I was concerned that psycopg replaces the %s placeholders using regexes, which might inadvertently alter my SQL queries. My goal was to ensure that my SQL queries were passed directly to PostgreSQL "as is," without any intermediate modifications. Only PostgreSQL's parser can safely and accurately parse all SQL queries. While this concern might seem theoretical if you're certain your queries don't contain any %s, it still felt much more reassuring to eliminate this potential source of bugs entirely.
> Unlike psycopg2, asyncpg implements PostgreSQL binary I/O protocol, which, aside from performance benefits, allows for generic support of container types (arrays, composites and ranges).
They are unrelated lineage wise, but accomplish similar things. One just happens to be substantially more performant than the other. I have been a psycopg user for many years but have started to utilize this lib in projects that rely on asyncio.
13 comments
[ 4.6 ms ] story [ 44.6 ms ] threadNot sure there is a compelling reason to stay with psycopg3 then if asyncpg exists.
Even though the latter was already safe, it simply looked toe-curling (like you were writing naive SQL-injectable queries all the time).
I was concerned that psycopg replaces the %s placeholders using regexes, which might inadvertently alter my SQL queries. My goal was to ensure that my SQL queries were passed directly to PostgreSQL "as is," without any intermediate modifications. Only PostgreSQL's parser can safely and accurately parse all SQL queries. While this concern might seem theoretical if you're certain your queries don't contain any %s, it still felt much more reassuring to eliminate this potential source of bugs entirely.
[1] https://www.psycopg.org/psycopg3/docs/advanced/cursors.html#...
Performance charts speak for themselves. This lib uses the binary protocol while most are using text based comms.