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
pgtype.Row() was optimized for a single line use
without much ceremony at a cost of OID registration,
which is cumbersome. In practice it so much incovnenience
to create new Composite just before making a query.
So now there is just a Composite type and 2 helper methods:
- SetFields sets composite fields to values passed. This assignment
fails if types passed are not assignable to Values pgtype is
made of.
- Scan acts exactly like query.Scan, but for a composite value. Passed
values are set to values from SQL composite.
Composite() function returns a private type, which should
be registered with ConnInfo.RegisterDataType for the composite
type's OID.
All subsequent interaction with Composite types is to be done
via Row(...) function. Function return value can be either
passed as a query argument to build SQL composite value out of
individual fields or passed to Scan to read SQL composite value
back.
When passed to Scan, Row() should have first argument of type
*bool to flag NULL values returned from query.
ScanRowValue is useful when reading ROW() values with
known field types as well as composite types. It accepts
pgtype.Value arguments, where ROW() fields are written to
on successfull scan.
PostgreSQL has microsecond precision. If more than this precision is
supplied in the text format it is rounded. This was inconsistent with
the binary format.
See https://github.com/jackc/pgx/issues/699 for original issue.
Previously Set would always return an error when called on a range type.
Now it will accept an instance of itself, a pointer to an instance of
itself, a string, or nil. Strings are parsed with the same logic as
DecodeText.
Methods defined on T are also available on *T. Thought this technically
changes the interface, because *T will be automatically dereferenced as
needed it shouldn't be a breaking change.
See a8802b16cc593842f5c69b0f7cfb0de11d5cd3a8 for similar change.
