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
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.
Andrew Kimball
Jonathan Amsterdam
Jack Christensen
zikaeroh
georgysavva
Bas van Beek
Alex Gaynor
Johan Brandhorst
Jonathan Yoder