Previously, stdlib.RegisterConnConfig would sometimes reuse the same connection
string for different ConnConfig options (specifically, it happened when a connection
was open and then closed, and then a new, different connection was opened). This
behavior interferes with callers that expect that two connections with the same data
source name are connecting to the same backend database in the same way.
This fix updates stdlib.RegisterConnConfig to use an incrementing sequence
counter to uniquify all returned connection strings.
Fixes#947
Increased data type support for simple protocol. Improved test
coverage of simple protocol. This has the additional advantage of
exercising the text encoders and decoders.
If a connection is in a transaction or has an open result set then
close the connection when returning it to database/sql. When next
database/sql attempts to use it the connection will return
driver.ErrBadConn and database/sql will remove it from the pool.
fixes#673
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 is in preparation for a Begin / Tx interface that will similate
nested transactions with savepoints.
In addition, this passes the TxOptions struct by value and thereby
removes an allocation.
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.
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
The Driver.configs map is protected by configMutex in
registerDriverConfig and unregisterDriverConfig, but not in Open. This
results in a race if Open is called while another goroutine is
registering/unregistering a DriverConfig.
database/sql/driver.Driver implementations can be nested, with each
layer adding additional functionality. If pgx/stdlib.Driver is wrapped
in another driver.Driver implementation, AcquireConn will error,
detecting that the *sql.DB's driver is not (directly) pgx.Driver.
It looks like it should be possible to support the current functionality
without requiring that the top-level Driver be pgx/stdlib.Driver, but
it requires using a global map of fakeTxConns instead of a per-Driver
map of fakeTxConns.
Is this reasonable?