This patch fixes jackc/pgx#841. The meat of the fix lives
in [a PR to the pgconn repo][1]. This change just checks
for errors after executing a prepared statement and informs
the underlying stmtcache about them so that it can properly
clean up. We don't try to get fancy with retries or anything
like that, just return the error and allow the application to handle it.
I had to make [some][1] [changes][2] to to the jackc/pgconn package as well
as this package.
Fixes#841
[1]: https://github.com/jackc/pgconn/pull/56
[2]: https://github.com/jackc/pgconn/pull/55
Previously, the Scan documentation stated that scanning into a []byte
will skip the decoding process and directly copy the raw bytes received
from PostgreSQL.
This has not been true for at least 2 months. It is also undesirable
behavior in some cases such as a binary formatted jsonb. In that case
the '1' prefix needs to be stripped to have valid JSON. If the raw
bytes are desired this can easily be accomplished by scanning into
pgtype.GenericBinary or using Rows.RawValues.
In light of the fact that the new behavior is superior, and that it has
been in place for a significant amount of time, I have decided to
document the new behavior rather than change back to the old behavior.
This was originally done to fix#386. But subsequent changes to pgtype
render the allocation unnecessary. Tests put in place with the original
fix still pass.
This allows handling queries where it is unknown if there will be a
result set or not. If it is not a result set returning query the
command tag will still be available.
It was a mistake to use it in other contexts. This made interop
difficult between pacakges that depended on pgtype such as pgx and
packages that did not like pgconn and pgproto3. In particular this was
awkward for prepared statements.
This is preparation for removing pgx.PreparedStatement in favor of
pgconn.PreparedStatement.
