This will be useful for array and composite types that may have to
support elements that may not support binary encoding.
It also is slightly more convenient for text-ish types to have a default
format of text.
PlanScan used to require the exact same value be used every time. While
this was great for performance, on further consideration I think it is
too much of a potential foot-gun.
This moves back in the other direction. A plan tolerates a change in
destination. It even detects a change in destination type and falls
back to a new plan.
Perfectly matched hot scan paths (e.g. PG int4 to Go int32) are still
much faster than they were before this set of optimizations. The first
scan of a destination that uses a decoder is faster due to not
allocating. It's a little bit slower on subsequent runs than before
this set of optimizations. But it is preferable to optimize for the
most common scan targets (e.g. *int32, *int64, *string) over generic
decoder destinations.
In addition this fees pgx.connRows.Scan from having to check that
the destination is unchanged.
This allows registering a mapping of a Go type to a PostgreSQL type
name. If the OID of a value to be encoded or decoded is unknown, this
additional mapping will be used to determine a suitable data type.
Instead of hardcoding specific types and skipping type assertions based
on that, only check if a destination is a (sql.Scanner) after a failed
AssignTo.
This is slightly slower in the non-decoder case and *very* slightly
faster in the decoder. However, this approach is cleaner and has the
potential for further optimizations.
Specifying behavior for Status Null and Undefined is incorrect because
a Value is not required to have a Status. In addition, standard
behavior is to return nil, not pgtype.Null when the Status is
pgtype.Null.
This comes at a small expense to scanning into a type that implements
TextDecoder or BinaryDecoder but I think it is a good trade.
Before:
BenchmarkConnInfoScanInt4IntoBinaryDecoder-16 88181061 12.4 ns/op 0 B/op 0 allocs/op
BenchmarkConnInfoScanInt4IntoGoInt32-16 30402768 36.8 ns/op 0 B/op 0 allocs/op
After:
BenchmarkConnInfoScanInt4IntoBinaryDecoder-16 79859755 14.6 ns/op 0 B/op 0 allocs/op
BenchmarkConnInfoScanInt4IntoGoInt32-16 38969991 30.0 ns/op 0 B/op 0 allocs/op
