I honestly fail to see (> cost) benefits of such tool. I realize it adds an additional layer abstraction which one could use to build additional functionalities on top, such as dialect translation, metadata emission. But why one would want to pay the cost of learning the new API and adhering limitation. For example, it is missing upsert feature. So what one supposed to do in this case?
This is what got my attention about it - it provides a link that makes it more natural to play with SQL from Rust. You get some protection from typos and type errors, and you get the benefit of working with native types. I'd feel more confident working in this environment for those reasons than I would working with string-based SQL directly in my program. As for the incompleteness issues, it's still young and that seems like a solvable problem to me.
Nowadays this technology seems almost completely forgotten, and I confess to being baffled as to why. Certainly existing implementations are execrable - just read up on indicator variables, or string handling, in Pro* C to see what I mean, but IMO the concept is sound if married to a modern 'host' language like C++ or Rust. One very strong advantage is that you are then actually writing your SQL in SQL, not using some baroque builder API.
As for typing, the precompiler could parse the SQL and see what result sets are being returned / what columns are being married to bind variables and so on, and then interrogate the database's metadata to determine their types. AFAIK no existing implementation does this.
this is a way of encoding SQL in Rust's syntax, which gives you compile-time verification of your queries, query composition, etc. in exchange for the fact that you're not writing queries as strings. of course it's missing features, that doesn't stop it from being useful. look at python's sqlalchemy for a great example of a DSL that's arguably better than SQL at being SQL.