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
This commit adds support for sending batches of queries via the Simple
protocol with SendBatch. The result appears identically to how it would
if it were created with the extended protocol.
A Config object may be created via ParseConfig and then further
modified. Requiring access to the original ConnString via the Config
helps indicate that the Config is the source of truth as to how the
connection was actually established.
IsAlive is ambiguous because the connection may be dead and we do not
know it. It implies the possibility of a ping. IsClosed is clearer -- it
does not promise the connection is alive only that it hasn't been
closed.
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.
This simplifies handling default values. Now there is no ambiguity
between a zero value and a default value. All default values are set by
ParseConfig and the user can modify them after the initial creation.
fixes#567
Also remove PrepareEx. It's primary usage was for context. Supplying
parameter OIDs is unnecessary when you can type cast in the query SQL.
If it does become necessary or desirable to add options back it can be
added in a backwards compatible way by adding a varargs as last
argument.
Instead of needing to instrospect the database on connection preload the
standard OID / type map. Types from extensions (like hstore) and custom
types can be registered by the application developer. Otherwise, they
will be treated as strings.
It is impossible to guarantee that the a query executed with the simple
protocol will behave the same as with the extended protocol. This is
because the normal pgx path relies on knowing the OID of query
parameters. Without this encoding a value can only be determined by the
value instead of the combination of value and PostgreSQL type. For
example, how should a []int32 be encoded? It might be encoded into a
PostgreSQL int4[] or json.
Removal also simplifies the core query path.
The primary reason for the simple protocol is for servers like PgBouncer
that may not be able to support normal prepared statements. After
further research it appears that issuing a "flush" instead "sync" after
preparing the unnamed statement would allow PgBouncer to work.
The one round trip mode can be better handled with prepared statements.
As a last resort, all original server functionality can still be accessed by
dropping down to PgConn.
Previously, a failed connection could be put back in a pool and when the
next query was attempted it would fail immediately trying to prepare the
query or reset the deadline. It wasn't clear if the Query or Exec call
could safely be retried since there was no way to know where it failed.
You can now call LastQuerySent and if it returns false then you're
guaranteed that the last call to Query(Ex)/Exec(Ex) didn't get far enough
to attempt to send the query. The call can be retried with a new
connection.
This is used in the stdlib to return a ErrBadConn if a network error
occurred and the statement was not attempted.
Fixes#427
CockroachDB doesn't support 80877102 and doesn't plan to, so instead allow
the user to customize the cancellation with their own function. In our
function, we call CANCEL QUERY with the query_id based on the LocalAddr().
The WaitForReady method can be used by a pool to not put a connection back
in the pool until it is finished cancelled and ready for a new query.
This addresses https://github.com/jackc/pgx/issues/321 with the
fix @jackc proposed there. Redshift users that need to connect
w/ SSL currently fork the library to delete this parameter, e.g.
8e0028d742
And, that's annoying to keep up-to-date :)
It's possible to define a type (e.g., an enum) with the same name in two
different schemas. When initializing data types after connecting, types
defined within schemas other than pg_catalog or public should be
qualified with their schema name to disambiguate them and ensure all
types with the same base name get added to the map of OID to type.
Prior to this commit, the last type scanned would "win", and all others
with the same name would be missing from the ConnInfo type maps, which
would subsequently cause any PREPARE involving columns of those missing
types to return the error "unknown oid".
This more appropriately aligns the behaviour of the library with
that advertised by the postgres documentation.
According to the table on the official documentation page
https://www.postgresql.org/docs/current/static/libpq-ssl.html,
the "require" mode should be used when:
"I want my data to be encrypted, and I accept the overhead. I trust that the network will make sure I always connect to the server I want."
This maps reasonably well to a TLS config that skips certificate verification.
Prior to this commit, execEx() would write the one round trip exec to
the connection before first calling ensureConnectionReadyForQuery, which
ultimately caused any errors to be suppressed if the exec followed a
valid query, because the receive message processing would finish
successfully as soon as it received the ReadyForQuery that actually
belonged to the preceding query. So, the exec would never actually
receive the error message that it caused, leaving it to be incorrectly
received by the first subsequent query sent.