Support Types that have a dynamic Postgres type

[fabianfett]

The current PostgresEncodable:

/// A type that can encode itself to a postgres wire binary representation.
public protocol PostgresEncodable {
    // TODO: Rename to `PostgresThrowingEncodable` with next major release

    /// identifies the data type that we will encode into `byteBuffer` in `encode`
    static var psqlType: PostgresDataType { get }

    /// identifies the postgres format that is used to encode the value into `byteBuffer` in `encode`
    static var psqlFormat: PostgresFormat { get }

    /// Encode the entity into the `byteBuffer` in Postgres binary format, without setting
    /// the byte count. This method is called from the ``PostgresBindings``.
    func encode<JSONEncoder: PostgresJSONEncoder>(into byteBuffer: inout ByteBuffer, context: PostgresEncodingContext<JSONEncoder>) throws
}

requires that all instances of a type are encoded into the same PostgresDataType because of the static requirement. This is bad, specifically because supporting custom types (like Postgres enums) requires a dynamic OID.

For this reason @gwynne proposes adding a PostgresDynamicTypeEncodable and PostgresDynamicTypeThrowingEncodable, that use dynamic psqlType and psqlFormat. PostgresEncodable should then inherit from the PostgresDynamicTypeThrowingEncodable and PostgresNonThrowingEncodable from PostgresDynamicTypeEncodable. Love how we ended up at the place with NonThrowing and just Throwing.

[fabianfett]

This issue blocks PostgresData deprecation.

[marius-se]

I almost have a compiling implementation, but it's getting late here so I'll continue with it tomorrow. Here's what I came up with syntax-wise - from the users perspective:

try await connection.query("""
INSERT INTO books (id, embedding)
VALUES (\(id), \(vector, as: PostgresDataType(16524), format: .binary)) // <---
""", logger: logger)

And on our end:

public protocol PostgresDynamicTypeNonThrowingEncodable {
    func encode<JSONEncoder: PostgresJSONEncoder>(
        into byteBuffer: inout ByteBuffer,
        context: PostgresEncodingContext<JSONEncoder>,
        psqlType: PostgresDataType,
        psqlFormat: PostgresFormat
    )
}

I'll set up a PR once it's compiling.

At some point I was looking at this and wondering if we really need this level of flexibility? For my personal use-case overwriting the types PostgresEncodable.psqlType is totally sufficient - I don't expect different instances of my type to have different oids. So just for my personal understanding: What are some examples where we'd need dynamic oids for the same Swift type?

[joshjacob]

@marius-se Re: Examples -- I was watching this issue because I had started a new project which potentially has an issue with the current implementation. My project (https://github.com/joshjacob/SwiftAge) adds an extension to postgres-nio to support Apache AGE (https://age.apache.org) which is an extension to PostgreSQL to support graph databases. Apache AGE has their own datatype which my project currently queries for. Since the oid for each install could be different, my project can't support multiple connections to different databases in the same runtime.

[marius-se]

Ahh that's a valid use case. Makes sense, thanks! I'll open a PR today/tomorrow.