Previously, PlanScan used a cache to improve performance. However, the
cache could get confused in certain cases. For example, the following
would fail:
m := pgtype.NewMap()
var err error
var tags any
err = m.Scan(pgtype.TextArrayOID, pgx.TextFormatCode, []byte("{foo,bar,baz}"), &tags)
require.NoError(t, err)
var cells [][]string
err = m.Scan(pgtype.TextArrayOID, pgx.TextFormatCode, []byte("{{foo,bar},{baz,quz}}"), &cells)
require.NoError(t, err)
This commit removes the memoization and adds a test to ensure that this
case works.
The benchmarks were also updated to include an array of strings to
ensure this path is benchmarked. As it turned out, there was next to no
performance difference between the cached and non-cached versions.
It's possible there may be a performance impact in certain complicated
cases, but I have not encountered any. If there are any performance
issues, we can optimize the narrower case rather than adding memoization
everywhere.
This preserves backwards compatibility in the unlikely event someone is
using an alternative XML unmarshaler that does support unmarshalling
into *any.
Rather than special case the reported issue with UUID and [16]byte, this
commit allows the system to find the underlying type of any type that is
an array.
fixes https://github.com/jackc/pgx/issues/2107
When `LoadTypes` is being called, it does not include the
namespace-qualified types in its result. While these namespaces are
visible to `LoadTypes` itself, `RegisterTypes` will not recognise this
form of the types, only allowing them to be used if they are on the
schema path, and referred to without their namespace component.
When loading even a single type into pgx's type map, multiple SQL
queries are performed in series. Over a slow link, this is not ideal.
Worse, if multiple types are being registered, this is repeated multiple
times.
This commit add LoadTypes, which can retrieve type
mapping information for multiple types in a single SQL call, including
recursive fetching of dependent types.
RegisterTypes performs the second stage of this operation.