A batch on a tx object does not open and close a transaction itself and
instead use the tx object to ensure the transactionality of the batch
remove unused boolean 'sent' in batch struct
* wingedpig-master:
Reverted breaking API change to CreateReplicationSlot. Instead, the new version that returns the consistent_point and snapshot_name values is called CreateReplicationSlotEx().
Changed CreateReplicationSlot to return the consistent_point and snapshot_name.
* 'master' of https://github.com/wingedpig/pgx:
Reverted breaking API change to CreateReplicationSlot. Instead, the new version that returns the consistent_point and snapshot_name values is called CreateReplicationSlotEx().
Changed CreateReplicationSlot to return the consistent_point and snapshot_name.
An incompletely read select followed by an insert would fail. This was
caused by query methods in the non-batch path always calling
ensureConnectionReadyForQuery. This ensures that connections interrupted
by context cancellation are still usable. However, in the batch case
query methods are not being called while reading the result. A
incompletely read select followed by another select would not manifest
this error due to it starting by reading until row description. But when
an incomplete select (which even a successful QueryRow would be
considered) is followed by an Exec, the CommandComplete message from the
select would be considered as the response to the subsequent Exec.
The fix is the batch tracking whether a CommandComplete is pending and
reading it before advancing to the next result. This is similar in
principle to ensureConnectionReadyForQuery, just specific to Batch.
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.
Bug was chooseParameterFormatCode would see that type could handle
binary format so binary format would be chosen. But
encodePreparedStatementArgument would see driver.Valuer first and
would encode with that -- which is text mode. So the server would
receive a text format value when expecting a binary format value.
Discovered while investigating #316
Since QueryRow delegates to Query, it needs Query to always return
non-nil *Rows to prevent a nil pointer deference when the QueryRow
caller calls Scan(). This commit fixes the few returns in QueryEx that
return nil on errors rather than *Rows with its err field set.
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.
Jack Christensen
Jack Christensen
André Bierlein
Felix Geisendörfer
Gaspard Douady
Gaspard Douady
Manni Wood
Mark Fletcher
Kelsey Francis
Johan Brandhorst
miktwon
Mike Graf