Existing generic helpers always call defer rows.Close().
Examples of their usage also omit external defer rows.Close() call.
For clarity, state that explicitly, because that's another point
why one would want to switch to generic helpers from manually written
rows.Next() loop.
Modify the RowToStructByPos/Name functions to store the computed mapping
of columns to struct field locations in a cache to reuse between calls.
Because this computation can be expensive and the same few results will
frequently be reused, caching these results provides a significant
speedup.
For positional mappings, we can key the cache by just the struct-type.
However, for named mappings, the key must include a representation of
the columns, in order, since different columns produce different
mappings.
QueryExecModeCacheDescribe actually is safe even when the schema or
search_path is modified. It may return an error on the first execution
but it should never silently encode or decode a value incorrectly. Add a
test to demonstrate and ensure this behavior.
Update documentation of QueryExecModeCacheDescribe to remove warning of
undetected result decoding errors.
Update documentation of QueryExecModeCacheStatement and
QueryExecModeCacheDescribe to indicate that the first execution of an
invalidated statement may fail.
The Rows interface in pgx, like its ancestor in database/sql, is easy to
accidentally misuse in a way that can cause apps to misinterpret
database or connection errors as successful queries with empty or
truncated result-sets.
Update the docs to emphasise the need to call rows.Err() after
rows.Next() returns false, and direct users of the interface to the v5
API helpers that make writing correct code easier.
The docs on Conn.Query() already call this out, so only a small change
is needed to warn users and point them at the details on Query()
Per details in #1707
Instead of using pgproto3.FieldDescription through pgconn and pgx. This
lets the lowest level pgproto3 still be as memory efficient as possible.
https://github.com/jackc/pgx/pull/1281
Previously, a batch with 10 unique parameterized statements executed
100 times would entail 11 network round trips. 1 for each prepare /
describe and 1 for executing them all. Now pipeline mode is used to
prepare / describe all statements in a single network round trip. So it
would only take 2 round trips.
- Remove rarely used ScanPlan.Scan arguments
- Plus other refactorings and fixes that fell out of this change.
- Plus rows Scan now handles checking for changed type.
