Rust中tokio_postgres Row的FromSql生命周期问题求解

问题1：为何UUID版本函数无报错？如何提前发现这类特性？ #

• UUID的FromSql实现是直接获取所有权的：它会把数据库返回的字节数据解析成独立的Uuid实例，完全不依赖原Row的内存。而很多其他类型（比如&str、&[u8]）的FromSql实现是借用Row内部的缓冲区，会绑定Row的生命周期，泛化时就会触发报错。
• 提前发现这类特性的方法：
  • 查看FromSql trait的关联类型Owned：如果Owned是值类型（比如Uuid），说明该类型可以脱离Row独立存在；如果是引用类型（比如&'a str），就会依赖Row的生命周期。
  • 查阅具体类型的FromSql实现文档，或者直接看源码实现，判断它返回的是所有权还是引用。
  • 写泛型函数时，先拿不同类型（比如引用类型和值类型）测试，提前暴露生命周期问题。

问题2：持有Row所有权，如何获取结果的所有权解决生命周期问题？ #

• 用row.get_owned()替代row.get()：tokio_postgres提供的get_owned()方法，专门用于获取所有权类型的结果，它会把数据从Row的缓冲区复制/解析成独立实例，完全不依赖Row的生命周期。
• 约束泛型参数实现FromSqlOwned trait：这个trait是FromSql的扩展，要求类型能从Row中获取所有权。你的泛型函数可以这样定义：

async fn get_first_column<T>(rows: Vec<tokio_postgres::Row>) -> Result<T, tokio_postgres::Error>
where
    T: tokio_postgres::FromSqlOwned,
{
    let row = rows.into_iter().next().ok_or(tokio_postgres::Error::from_sql_null())?;
    row.get_owned(0)
}

• 注意：即使Vec<Row>本身没有生命周期标注，Row内部的字段可能是引用数据库的临时缓冲区，所以get()返回的引用会绑定到Row的生命周期，而get_owned()会打破这个绑定。之前尝试clone无效，大概率是因为你克隆的是Row本身，而非get()返回的引用类型——如果get()返回的是&str，需要克隆它得到String，但直接用get_owned()能一步获取所有权类型。

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