Cross-language interop: implications for native protocol drivers (asyncpg, pgx, tokio-postgres)

[arkstack-dev]

Most of the spec's framing assumes a libpq-style client. But several widely-used drivers implement the v3 wire protocol natively rather than wrapping libpq — asyncpg (Python), pgx (Go), tokio-postgres (Rust), and others. Those are exactly the implementations that would carry a QUIC binding directly, with no libpq layer to hide transport details.

This thread is to surface whether anything in the binding is awkward, underspecified, or wrong from a native-driver perspective.

Areas I think are relevant (correct me where I'm off):

• Stream model (§3). One session per bidirectional stream. A native driver maintaining a pool today maps "pool of N connections" to "N sockets." Under this binding it becomes "N streams on one QUIC connection." That's a structural change to how a driver's pool layer thinks about resources — is the one-session-per-stream rule the right granularity, or do some drivers want multiple short sessions multiplexed differently?

• Cancellation (§7). Native drivers implement cancel themselves rather than calling PQcancel. §7 replaces the second-connection CancelRequest with STOP_SENDING. For an async driver, issuing STOP_SENDING on a stream is arguably simpler than opening a second connection from an event loop — but I want to hear whether the no-op-on-idle race resolution (§7 para 2) maps cleanly onto how these drivers track in-flight queries.

• Framing (§4). v3 messages on the stream, no extra framing, message boundaries may not align with QUIC STREAM frame boundaries. Native drivers already handle "v3 message split across TCP segments," so this should be familiar — but I'd like confirmation that the existing message-reassembly logic ports without surprises.

Open questions:

1. For native drivers: does anything in §3–§7 assume libpq semantics that don't hold for a native implementation?
2. Pooling: is one-session-per-stream the right model, or does it fight with how existing native-driver pools are structured?
3. Is there a driver-side reason to want server-initiated streams (currently forbidden, §3.3) that I'm not seeing — e.g. for NOTIFY delivery without occupying the session stream?

If you maintain or have worked on a native-protocol driver, the specific thing I want is: "here's where the binding assumes something my driver doesn't do."