Jack Christensen

This functionality has just become available in pgx v5 in 8649231bb3bc00b4b9c180ce557a54ae41c28ce2 and 33360ab479cc29dd23adb848504bad01b7ff25b3. I'd prefer not to add a different approach to v4.

You can use [RegisterConnConfig](https://pkg.go.dev/github.com/jackc/pgx/[email protected]/stdlib#RegisterConnConfig) when you have to use `sql.Open`.

I would prefer to avoid adding global variables. I also don't won't to make a special case for how to customize one particular type. The Codec system should be used...

First, I suggest using the package github.com/jackc/pgx/v5/pgproto3 instead of this package. This package was merged into pgx v5 well over a year ago. Second, I'm not sure what's going in...

I'm using the standard Go benchmarking tools. It be great if there was an automated way to make the output more clear, but personally I don't know of any. Visualization...

> add a new blank line after each group I'm not actually sure how to do this with `testing` package -- at least without putting print statements in the tests...

Unless you have a very unusual use case you shouldn't need to use `pgtype.JSON` directly at all. Just use a `string` or `[]byte` directly.

Hmm... That might be interesting. The whole `string` vs `[]byte` thing with JSON has caused problems before. It might work to just change it in `Value()` but I'm not sure...

I have not tried it with `ltree` but for my custom types I do something like this. ```go dataTypeNames := []string{ "foo", "_foo", } for _, typeName := range dataTypeNames...

> I'd guess it's related to the fact that ($1::text[])::ltree[] sends Postgres text[] and Postgres converts it to ltree[] once it starts executing the query. With $1::ltree[], Postgres expects the...