Fixes an issue where empty values were treated as null values and vica versa

This patch was authored by @fabianfett and released by @0xTim.

Fix encoding and decoding optional values to and from the database due to a regression in #135. Resolves #143 (#144)

State machine

This patch was authored by @fabianfett and released by @0xTim.

Motivation

Connection state changes can be modeled with state machines. This PR introduces a ConnectionStateMachine that models the PostgresConnection's state. This will improve the Unit-testability of this package.

Changes

• This PR does not change any public API
• It replaces the underlying implementation of PostgresConnection with a new PSQLConnection
• All new classes and structs that support the new PSQLConnection live in the /New folder
• The PSQLConnection is mainly implemented using these structs and classes:
  • PSQLFrontendMessage a new enum modeling outgoing client messages to the server
  • PSQLBackendMessage a new enum modeling incoming server messages to the client
  • PSQLFrontendMessage.Encoder a new MessageToByteEncoder
  • PSQLBackendMessage.Decoder a new ByteToMessageEncoder
  • ConnectionStateMachine with the sub state machines:
    • AuthenticationStateMachine
    • CloseStateMachine
    • ExtendedQueryStateMachine
    • PrepareStatementStateMachine
  • PSQLChannelHandler is the main ChannelDuplexHandler for the PSQLConnection
  • PSQLEventsHandler is a new ChannelHandler that observes the channel events and closes the connection when appropriate.
  • PSQLEncodable is a new protocol to convert Swift types to Postgres types.
  • PSQLDecodable is a new protocol to convert Postgres types to Swift types.
  • PSQLEncodable and PSQLDecodable defer the encoding and decoding as much as possible, saving unnecessary allocations and conversions.
• Thanks to these changes extended queries and prepared statements will now take the same code paths. Thus we ensure that code improvements for one query type will also lead to improvements for the other.

Result

We get a better testable PostgresConnection.

State machine

This patch was authored by @fabianfett and released by @0xTim.

Motivation

Connection state changes can be modeled with state machines. This PR introduces a ConnectionStateMachine that models the PostgresConnection's state. This will improve the Unit-testability of this package.

Changes

• This PR does not change any public API
• It replaces the underlying implementation of PostgresConnection with a new PSQLConnection
• All new classes and structs that support the new PSQLConnection live in the /New folder
• The PSQLConnection is mainly implemented using these structs and classes:
  • PSQLFrontendMessage a new enum modeling outgoing client messages to the server
  • PSQLBackendMessage a new enum modeling incoming server messages to the client
  • PSQLFrontendMessage.Encoder a new MessageToByteEncoder
  • PSQLBackendMessage.Decoder a new ByteToMessageEncoder
  • ConnectionStateMachine with the sub state machines:
    • AuthenticationStateMachine
    • CloseStateMachine
    • ExtendedQueryStateMachine
    • PrepareStatementStateMachine
  • PSQLChannelHandler is the main ChannelDuplexHandler for the PSQLConnection
  • PSQLEventsHandler is a new ChannelHandler that observes the channel events and closes the connection when appropriate.
  • PSQLEncodable is a new protocol to convert Swift types to Postgres types.
  • PSQLDecodable is a new protocol to convert Postgres types to Swift types.
  • PSQLEncodable and PSQLDecodable defer the encoding and decoding as much as possible, saving unnecessary allocations and conversions.
• Thanks to these changes extended queries and prepared statements will now take the same code paths. Thus we ensure that code improvements for one query type will also lead to improvements for the other.

Result

We get a better testable PostgresConnection.

Make PostgresNIO tests non throwing

This patch was authored by @fabianfett and released by @0xTim.

Refactor all remaining PostgresNIO tests to get better error diagnostics in case of unexpected errors. (#141)

Follow up to #140.

Remove unintended SASL print statement

This patch was authored by @fabianfett and released by @gwynne.

We currently print the internal SASL state when authenticating via SCRAM-SHA256. This messes up logs and is a potential security issue.

Modifications

• Remove a print statement

Support for SCRAM-SHA-256 SASL authentication

This patch was authored and released by @gwynne.

• PostgreSQL supports SCRAM-SHA-256 authentication since version 11. This is preliminary support for that authentication type.

Close connection if requestTLS fails

This patch was authored and released by @0xTim.

Correctly close the PostgreSQL connection if requestTLS fails.

Resolves #133

Support custom JSON coders

This patch was authored by @jordanebelanger and released by @tanner0101.

Add support for custom, non-Foundation, JSON encoder & decoder through global variables PostgresNIO._defaultJSONEncoder and PostgresNIO._defaultJSONDecoder (#125, fixes #126).

Fix prepare(query:) when no data returned

This patch was authored by @Jerry-Carter and released by @tanner0101.

Fixes prepare(query:) when used with queries that return no results (like DELETE ...) (#123, fixes #122).

Integer overflow fixes

This patch was authored and released by @tanner0101.

Deprecates PostgresData integer conversion methods that could lead to overflow errors (#120, fixes #119).

Using the following types in release-mode should no longer be susceptible to overflow (or underflow) crashes:

• UInt
• Int8
• UInt16
• UInt32
• UInt64

⚠️ However, these types will still be interpreted incorrectly by Postgres since it doesn't have native support for them. This could create problems with other clients connecting to the database. To prevent such issues, using these types will now result in a debug-mode only assertion.

To migrate away from these types, there are two options:

1: Use a wider integer (or type) that does not overflow or underflow.

For example:

• Int8 -> Int16
• UInt16 -> Int32
• UInt32 -> Int (Int64)
• UInt / UInt64 -> String

The caveats with this method are increased storage size and a database migration is required.

2: Do an explicit bitPattern conversion to the inversely signed type with same bit width.

For example, using Fluent:

// Store the value as `Int32` in Postgres
@Field(key: "foo")
var _foo: Int32

// Access the value as if it were a `UInt32`. 
var foo: UInt32 {
    get {
        .init(bitPattern: self._foo)
    }
    set {
        self._foo = .init(bitPattern: newValue)
    }
}

The caveat with this method is that other clients may misinterpret the stored value.