A single Connect("connstring") may actually make multiple connection
requests due to TLS or HA configuration. Previously, when all attempts
failed only the last error was returned. This could be confusing.
Now details of all failed attempts are included.
For example, the following connection string:
host=localhost,127.0.0.1,foo.invalid port=1,2,3
Will now return an error like the following:
failed to connect to `user=postgres database=pgx_test`:
lookup foo.invalid: no such host
[::1]:1 (localhost): dial error: dial tcp [::1]:1: connect: connection refused
127.0.0.1:1 (localhost): dial error: dial tcp 127.0.0.1:1: connect: connection refused
127.0.0.1:2 (127.0.0.1): dial error: dial tcp 127.0.0.1:2: connect: connection refused
https://github.com/jackc/pgx/issues/1929
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.
If ScanLocation is set, the timestamps will be assumed to be in the
given location when scanning from the database.
The Codec interface is now implemented by *pgtype.TimestampCodec instead
of pgtype.TimestampCodec. This is technically a breaking change, but it
is extremely unlikely that anyone is depending on this, and if there is
downstream breakage it is trivial to fix.
https://github.com/jackc/pgx/issues/1195https://github.com/jackc/pgx/issues/1945
If ScanLocation is set, it will be used to convert the time to the given
location when scanning from the database.
The Codec interface is now implemented by *pgtype.TimestamptzCodec
instead of pgtype.TimestamptzCodec. This is technically a breaking
change, but it is extremely unlikely that anyone is depending on this,
and if there is downstream breakage it is trivial to fix.
https://github.com/jackc/pgx/issues/1195https://github.com/jackc/pgx/issues/1945
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.
It is more often that interesting information is buried by the verbose
output than the verbose output is useful. It can be reenabled later if
necessary.
Tests were failing with:
Error: Process completed with exit code 143.
This appears to mean that Github Actions killed the runner.
See https://github.com/jackc/pgx/actions/runs/8216337993/job/22470808811
for an example.
It appears Github Actions kills runners based on resource usage. Running
tests one at a time reduces the resource usage and avoids the problem.
Or at least that's what I presume is happening. It sure is fun debugging
issues on cloud systems where you have limited visibility... :(
fixes https://github.com/jackc/pgx/issues/1934
This still solves the problem of negative numbers creating a line
comment, but this avoids breaking edge cases such as `set foo to $1`
where the substition is taking place in a location where an arbitrary
expression is not allowed.
https://github.com/jackc/pgx/issues/1928
pgx v5 was not vulnerable to CVE-2024-27289 do to how the sanitizer was
being called. But the sanitizer itself still had the underlying issue.
This commit ports the fix from pgx v4 to v5 to ensure that the issue
does not emerge if pgx uses the sanitizer differently in the future.
The PostgreSQL server will reject messages greater than ~1 GB anyway.
However, worse than that is that a message that is larger than 4 GB
could wrap the 32-bit integer message size and be interpreted by the
server as multiple messages. This could allow a malicious client to
inject arbitrary protocol messages.
https://github.com/jackc/pgx/security/advisories/GHSA-mrww-27vc-gghv
The underlying type of json.RawMessage is a []byte so to avoid it being
considered binary data we need to handle it specifically. This is done
by registerDefaultPgTypeVariants. In addition, handle json.RawMessage in
the JSONCodec PlanEncode to avoid it being mutated by json.Marshal.
https://github.com/jackc/pgx/issues/1763
Mitar
Jack Christensen
ngavinsir
Oleksandr Redko
Pavlo Golub
Carlos Pérez-Aradros Herce
WGH
Oleksandr Redko
Zach Olstein
Felix Röhrich
Tomas Zahradnicek
Felix