I notice that this library is similar to sqldelight, but limited to PostgreSQL.

[khassar00]

I used to use sqldelight on the kotlin language.SQLDelight can also generate type-safe apis from SQL statements.Does cornucopia have more goals?

[dlight]

My 2 cents: I think that being limited to PostgreSQL makes it easier to support all features of this particular db, instead of supporting a common denominator of multiple dbs.

[LouisGariepy]

@khassar00 Thanks for your interest in Cornucopia.

The answer to your question is twofold. First, SQL databases expose type information in wildly different capacities. At some point we considered adding SQLite support, but we quickly realized that SQLite only exposes very weak typing information, making it basically useless for the goals that Cornucopia tries to achieve (i.e. strong typing integrations).

Secondly, driver implementation APIs vary quite a bit, making it difficult to create consistent abstractions over them.

As a maintainer, my focus is to make cornucopia as ergonomic and powerful as possible while keeping it reasonably maintainable. Trying to support a multitude of SQL servers would make these goal difficult to achieve.

What could happen in the future is that we expose generic facilities for type registration and code generation APIs so third-parties can develop specialized offshoots of Cornucopia for their preferred SQL dialects. I'd even be willing to include well-maintained offshoots in the cornucopia org to make them "official". This is just speculation on my part: for now I only have time to work on Postgres, so it would require some coordinated community effort to get there.

I hope this clarifies things 😄

[khassar00]

Thanks for your reply.
I expect cornucopia to have sqlite support in the future.
I have tried a few other crate, and compared to sqlx and Rusqlite, I find the hassle more than the benefit.
After getting used to using sqldelight, using these crates feel a little uncomfortable.SQL debugging is much faster than programming languages.