pgdog learns to count past 2.2 billion

Postgres OIDs are unsigned 32-bit integers. pgdog was treating them as signed. For most databases, this distinction is academic — until your schema has churned through enough objects that OIDs exceed 2.2 billion, at which point pgdog's type coercion turned valid OIDs into negative garbage. #873 swaps i32 for u32. The kind of fix that's one line to write and years to discover. Also in v0.1.36: count(*) was returning the wrong type when aggregating across shards (#872), and streaming replication was quietly dropping child table rows during resharding (#880). Three data integrity bugs, one release.

Wrap a SELECT ... FOR UPDATE in a CTE, and pgdog's query router used to miss it entirely — sending your locking query to a read-only replica, which responds with error 25006 and a polite refusal. The detection logic wasn't recursive. #879 teaches it to descend into CTEs. Straightforward fix once you realize the parser was only looking at the outer query. The issue came from production, naturally.

JavaScript's Number type loses precision past 2^53. If your sharded IDs are 64-bit integers that get JSON-serialized to a frontend, you're rolling the dice every time. #858 adds a 53-bit unique ID generator — still globally unique across shards, but safe for JavaScript's unfortunate numeric limitations. There's also a new pgdog.install_sharded_sequence() function (#881) that works cross-shard, so you can set this up from any node without coordinating manually.