4 ms·
The state of Go PostgreSQL drivers is pretty bad IMO. Everyone recommends pgx, but it has a few rough edges (like how it handles dates/time) and a lot of surfa
by candiddevmike 5y ago
The state of Go PostgreSQL drivers is pretty bad IMO. Everyone recommends pgx, but it has a few rough edges (like how it handles dates/time) and a lot of surface area. The other driver, lib/pq, isn't really being maintained (for no good reason, it's quite good, simple and works well with sqlx).
- benhoyt 5y agoI haven't used pgx -- can you give some specifics of the issues with dates/times or other rough edges?
- candiddevmike 5y agoThe way it parses dates using Unix time causes issues when you compare the values returned due to Go setting the location property: https://github.com/jackc/pgx/issues/863 https://github.com/jackc/pgx/issues/863 pgx doesn't seem to handle reconnects the same way lib/pg does, but I haven't tested this recently: https://github.com/jackc/pgx/issues/672 https://github.com/jackc/pgx/issues/672
- henvic 5y agoThe rough edges I've faced are either edge case bugs or using more obscure APIs. Nothing too much worrisome.
- henvic 5y agoI don't know the state of drivers for other ecosystems, but even though pgx has a few rough edges, the quality of the driver is quite good and the maintainer (jackc) is also super responsive and helpful. I've had a positive experience with the project.
- Ingon 5y agoOur issue with lib/pq is that it doesn’t respect context deadlines/cancellation - e.g. a long running query will keep running till its done (in postgres), even when the context and all the callers have been long gone. We had quite a few issues with this and RDS eventually exhausting (burst) balances, driving the performance of the rest of the system to the ground.