Rust中如何从闭包返回满足tokio_postgres ToSql trait的类型？

实现方案推荐 #

优先选择第二种思路，第一种思路存在无法解决的生命周期先天缺陷：你尝试返回的引用指向闭包内部创建的临时数组，闭包执行结束后临时数组就会被销毁，返回的引用必然是悬垂引用，仅修改类型标注无法解决根本问题。

具体实现代码 #

1. 封装copy_in通用函数

use tokio_postgres::{Client, Error, Type};
use tokio_postgres::types::ToSql;

async fn copy_in<T>(
    client: &mut Client,
    table_name: &str,
    columns: &[&str],
    col_types: &[Type],
    rows: &[T],
    mut row_mapper: impl FnMut(&T, &mut Vec<&(dyn ToSql + Sync)>),
) -> Result<u64, Error> {
    // 构造COPY语句
    let col_str = columns.join(", ");
    let copy_stmt = format!("COPY {table_name} ({col_str}) FROM STDIN BINARY");
    let sink = client.copy_in(&copy_stmt).await?;
    let mut writer = tokio_postgres::binary_copy::BinaryCopyInWriter::new(
        sink,
        col_types
    );

    // 预创建复用的行缓冲区，避免每行重复分配内存
    let mut row_buf = Vec::with_capacity(columns.len());

    for row in rows {
        // 清空缓冲区残留的上一行引用
        row_buf.clear();
        // 调用闭包填充当前行的字段引用
        row_mapper(row, &mut row_buf);
        // 写入当前行数据
        writer.write(&row_buf).await?;
    }

    // 完成写入返回影响行数
    writer.finish().await
}

2. 调用示例

// 你的业务结构体
struct MyRow {
    id: i32,
    name: String,
    range_begin: i32,
    range_end: i32,
}

// 实际调用代码
let rows_of_struct_data = vec![/* 你的业务数据 */];
let rows_affected = copy_in(
    &mut client,
    "table_name",
    &["col1", "col2", "col3", "col4"],
    &[Type::INT4, Type::VARCHAR, Type::INT4, Type::INT4],
    &rows_of_struct_data,
    |m, buf| {
        // 按列顺序往缓冲区推送字段引用即可，无需处理复杂类型转换
        buf.push(&m.id);
        buf.push(&m.name);
        buf.push(&m.range_begin);
        buf.push(&m.range_end);
    }
).await?;

原报错原因说明 #

1. 第一种思路的类型报错：

expected &dyn ToSql + Sync, found trait object dyn ToSql

本质是临时数组中的trait对象默认未携带Sync约束，即使手动添加约束，也无法解决临时数组生命周期短于外部使用逻辑的悬垂引用问题。

2. 第二种思路之前的生命周期报错：

reference to row escapes the async closure body here

是因为旧写法中row的引用被存储到了生命周期长于当前行的对象中，当前实现中缓冲区每次处理完一行就清空，引用仅在当前行的写入逻辑中生效，完全不会逃逸出当前行的作用域，生命周期天然合法。

方案优势 #

• 无额外堆分配开销，缓冲区全程复用，性能优于每行新建Vec的实现
• 闭包逻辑直观，增减字段仅需修改闭包内的push逻辑，完全满足避免重复代码的需求
• 无复杂生命周期标注，所有生命周期可被编译器自动推导，不会出现诡异的生命周期错误

内容的提问来源于stack exchange，提问作者ecoe