Jack Christensen

The basic functionality would be easy to implement. But even at the application layer there are subtle decisions involved in retry logic. I have no objection to something like what...

So I wasn't planning on working on this, but a few ideas came to me this morning and I poked at the idea for a little while. I didn't get...

Your last example is what looks best to me. For the sake of application correctness I think that using a transaction should be the general rule. But it'd be easy...

As mentioned above, it's very unlikely that something like this will land in core pgx. And definitely not without some positive reports from people using it in production. However, for...

> Currently, the LRU cache of prepared statements in pgx.Conn is [using the query string as cache key](https://github.com/jackc/pgx/blob/8e341e20f353830131c92f6f0fdda90ab95a3ad9/conn.go#L434). This makes it tricky in our project where a query builder is...

> Alternatively: Add support for metadata on a pgx.Conn This has just been added in 6f0deff0156a7ffcd557eac1011ebb5ce73739d3.

See https://github.com/jackc/pgx/issues/1630.

@reza-ebrahimi See https://github.com/jackc/pgx/issues/1630#issuecomment-1576823340

That keep alive value goes all the way back to b46ee0a9512cb0a375e3bcd0c4fbc6c05bdf3843 in 2014. At the time Go did not have TCP keepalive enabled by default. If a change is to...

Sorry, I actually don't know any good way for an application to get that behavior back. Typed nils caused a lot of headaches in pgtype and normalizing them at the...