Jack Christensen

@hmoazzem I don't see how that code relates to scanning a binary `timestamp` into a `*string`.

@hmoazzem `uint32` or https://pkg.go.dev/github.com/jackc/pgx/[email protected]/pgtype#Uint32 if you need it to be nullable.

pgx uses the PostgreSQL extended protocol by default. The extended protocol can only execute prepared statements -- in a sense -- there is a special nameless and ephemeral prepared statement...

> From a quick skim through the docs & code, it seems that there are no server-side resources that are held when using ModeDescribe. So what if pgx.Batch held a...

@sweatybridge Same issue as above. All statements are prepared before any statements are executed. Preparing `INSERT INTO batchtest VALUES (1)` fails because `batchtest` doesn't exist yet.

@makalaaneesh If it can be reliably done -- sure.

I think this is actually working as designed. The underlying `poll.DeadlineExceededError: i/o timeout` is an implementation detail. pgx uses `SetDeadline` to interrupt connections when a context is canceled. `normalizeTimeoutError` so...

While in theory I would prefer to use Go rather than another language and avoid the Ruby dependency, for templates I am not convinced. The erb templates are self-contained. But...

> My hypothesis is that there is a statement timeout in the PREPARE but after Postgres has actually created the prepared statement. This causes the pgx to end up in...

This seems like a good idea to me. Not sure on whether this configuration should go on `pgtype.Type` or `pgtype.ArrayCodec`. Either way, the `pgx.Conn.LoadType` and `pgx.Conn.LoadTypes` methods should also be...