On Mon, Sep 8, 2025 at 12:35 PM Dominique Devienne via Boost <boost@lists.boost.org> wrote:
And as Klemens wrote, you don't have to have to duplicate APIs you can into, or templatize them, just because the connection is owning or not.
There was a suggestion to add `connection_ref`, which is implicitly constructible from `connection`. Practically, when we pass a connection, the callee is aware of its ownership, because if it receives an owned connection, it probably needs to transfer it somewhere, unless we are dealing with coroutines or similar models, where the caller cannot preserve ownership of an object during execution, but that is a different story.
I think maybe people don't realize that SQLite is an *embedded* DB engine. The very term resultset is misleading. There's no resultset type in SQLite, like there is in PostgreSQL's LIBPQ for example. The term resultset give the impression the result of a query is "materialized" somehow. It's NOT!
Yes, I think the problem boils down to the fact that a resultset is tied to a statement, and trying to make it an owning type causes confusion around lifetime management and gives the false impression that multiple resultsets can exist for a single statement. It might be better to merge the functionality of resultset to statement and leave resultset as a reference type that is constructible from a statement (and possibly rename it to resultset_ref). This way, usages like the following will remain possible without having to pass a statement& around: void print(std::ostream &os, sqlite::resultset rw)