@Emyrk could you maybe update the PR description with what problem this is solving? I'm trying to understand how badly we need joins. Introducing an alternative way to do queries that involves a custom generator seems like a lot of complexity for us to support just for a few queries. I'm wondering if we could maybe do something that's simpler even if it's way less elegant.

@Emyrk could you maybe update the PR description with what problem this is solving? I'm trying to understand how badly we need joins. Introducing an alternative way to do queries that involves a custom generator seems like a lot of complexity for us to support just for a few queries. I'm wondering if we could maybe do something that's simpler even if it's way less elegant.

Yes this is just reverting back in this PR.

See the original PR: #6429
And the issue: #6426

It just seems like to me that the optimization is a bit premature. We're currently under 10 DB calls for a round trip which is practically nothing. Im just hesitant to introduce an alternate form of sql gen when I'm not aware of the status quo impeding us (even if it's not perfect). Do you think this is something we could kick down the road until it becomes a real issue?

It just seems like to me that the optimization is a bit premature. We're currently under 10 DB calls for a round trip which is practically nothing. Im just hesitant to introduce an alternate form of sql gen when I'm not aware of the status quo impeding us (even if it's not perfect). Do you think this is something we could kick down the road until it becomes a real issue?

This PR is not for performance. It is to enable using JOIN, which we can't really do. And it is to support dynamic queries so I can implement negated search queries: #6439. So you can search not x in the search (tbd syntax, github issues does -name:emyrk).

Right now without dynamic queries and joins, some things are difficult to implement cleanly. We have to double all our CASE WHEN clauses, or potentially even more. For authorized queries we do a strings.Replace on a sql comment.

Dynamic queries open up a lot of search behavior that we can also just no do right now. We cannot change sort order in sqlc.

Tabling until we need better search