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.
If the Write call in sendPreparedQuery encountered a non-fatal error - which means it sent
no bytes. It still was marking the connection as not ready for query. That caused the next
call to hang.
QueryEx was calling termContext and rows.fatal on err of sendPreparedQuery.
rows.fatal calls rows.Close which already calls termContext. This sequence of
calls was causing underlying io timeout errors to be returned instead of context
errors.
In addition, added fatalWriteErr helper method to allow recovery of write
timeout errors where no bytes were written.
This should solve flickering errors on Travis.