souf (Jun 20 2026 at 14:00): souf (Jun 20 2026 at 14:00):Hi,
When working with db (or other data sources) with a typed language we often need to write types that match a specific db query.
For example a type "Movie" with id, title, description, rating. Sometimes for performances reason we will query only the id and rating, sometimes only the id and title, etc...
Some language are quite inflexible in that regards, it ends up in having many types to represent all possible sub sets of a main type. Some are quite flexible for example Typescript with pick/omit/partial, but end up quite verbose in my opinion.
Some have pattern that help with not having to write the types at all, for example Rust and its macros (notably sqlx crate in mind which in my experience is the best library I have ever used to work with typed queries devX-wise), and it also integrates brilliantly with the LSP which make it easy to work with.
I wanted to know if there are some plans in Roc to make this easy to deal with?
Thanks!
Anton (Jun 20 2026 at 15:19):I think record builders cover that? See also roc-pg
souf (Jun 22 2026 at 09:14):Anything that would let us infer types automatically from a SQL query directly in the Roc code, like sqlx does via Rust macros?
souf (Jun 22 2026 at 09:15):sqlc could be useful as well but it is a different approach. I'm interested in knowing if there are plans/features to do that from the Roc sources code directly.
It seems that macro wouldn't be a thing in roc though, because it's adding complexity/slowing down the compiler?
Luke Boswell (Jun 22 2026 at 09:21):You could "parse" an SQL string at compile time into a typed parser
Luke Boswell (Jun 22 2026 at 09:21):I haven't tried anything like that yet, but it should be possible
Jonathan (Jun 22 2026 at 10:31):Luke Boswell said:
You could "parse" an SQL string at compile time into a typed parser
Is this something like, at comptime the query string can be parsed with an applicative parser and return a curried function that accepts the types required? Nope, nevermind.
Jonathan (Jun 22 2026 at 10:33):Bit of a word salad, but I'm asking because after looking at roc-parser I'm quite excited by applicative parsing, which is new to me.
souf (Jun 22 2026 at 10:35):@Luke Boswell I'm not sure how it would work? Is there a hook or something in the roc system that allows extending the compiler? If yes, would it work well with the LSP as well?
Jonathan (Jun 22 2026 at 10:39):I guess if your query parser evaluates to a query plan, that can be evaluated and validated by a pure function at comptime.
souf (Jun 22 2026 at 10:39):I'm asking, because since I worked with sqlx in Rust, every other approach feels like legacy and harder to work with. So I'd really love to do something similar in Roc, where I don't have to worry about type that can be inferred from the DB in the first place (query output and input parameters)
souf (Jun 22 2026 at 10:43):@Jonathan what sqlx does, is that it connects to the PG database and asks it to review the query that you wrote, PG returns metadata that contains input params/query output types, that are used to map everything via the rust macro system. It's even better than having a query parser in roc, because, first you don't have to maintain it, and secondly it will handle every possible edge case or configuration directly from PG! (and once again you get errors/completion directly in the LSP)
souf (Jun 22 2026 at 10:46):And Rust has made very hard work to get the LSP to interpret Macro on the fly, which is an insane work, but also is probably slowing down things quite a bit. That's why I think this approach might not fit Roc and the focus on extra fast compilation.
Anton (Jun 22 2026 at 12:19):souf said:
Luke Boswell I'm not sure how it would work? Is there a hook or something in the roc system that allows extending the compiler? If yes, would it work well with the LSP as well?
I think Luke is referring to the automatic evaluation of all top level constants that is done at compile time.
Last updated: Jul 23 2026 at 13:15 UTC