async fn create_records(tx: &mut Transaction<Postgres>, records: &[Record]) -> Result<(), Error> {
    if records.is_empty() {
        return Ok(());
    }

    let mut query_builder: QueryBuilder<Postgres> = QueryBuilder::new(
        // Note the trailing space
        "INSERT INTO records
            (id, some_data) ",
    );

    query_builder.push_values(records, |mut query_builder, record| {
        query_builder
            .push_bind(record.id)
            .push_bind(&record.some_data);
    });

    let query = query_builder.build();
    query
        .execute(tx)
        .await
        .map_err(|err| Error::Unspecified(format!("create_records: {err}")))?;

    return Ok(());
}

socat address chains concatenate internal modules that communicate bidirectionally. For example, a chain that establishes encrypted connection to a socks server might look something like this (parameters and options dropped):

"SOCKS:... | OPENSSL-CLIENT | TCP:..."

If you have a program that implements a new encryption protocol the chain could be changed to:

"SOCKS:... | EXEC:myencrypt.sh | TCP:..."

The complete example:

socat - "SOCKS:www.domain.com:80 | EXEC:myencrypt.sh | TCP:encrypt.secure.org:444"

The myencrypt.sh script would be a wrapper around some myencrypt program. It must adhere a few rules: It reads and writes cleartext data on its left side (FDs 0 and 1), and it reads and writes encrypted data on its right side (FDs 3 and 4). Thus, cleartext data would come from the left on FD 0, be encrypted, and sent to the right side through FD 4. Encrypted data would come from the the right on FD 3, be unencrypted, and sent to the left side through FD 1. It does not matter if the encryption protocol would required negotiations or multiple packets on the right side.