Previously, Get implicitly allowed returning a reference to an internal
value (e.g. a []byte) but AssignTo was documented as requiring a deep
copy.
This inconsistency meant that either Get was unsafe or the deep copy in
AssignTo was superfluous. In addition, Scan into a []byte skips going
through Bytea and returns a []byte of the unparsed bytes directly. i.e.
a reference not a copy.
Standardize on allowing Get and AssignTo to return internal references
but require a Value never mutate internal values - only replace them.
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.
