@schuttsm: This isn't ready for review/merge (I don't like the implementation), but I'm opening a pull request for discussion purposes & so I don't lose track of it.
The problem with this implementation is that it's too specific to JOINs. Instead, there should be a common function that is used wherever a table name can be used, that can also take a SQL statement and render it as a subquery.
I'm also not so sure about the API of putting .as() on the statement itself... perhaps that is the best place, but it's a bit ambiguous whether that's where you land if you're trying to follow SQL as closely as possible... i could imagine someone expecting it to be an argument to .join() or a method on the outer query... similar to .join().on(), it could be .join().as().on(). Anyway, it's worth thinking about.
@schuttsm: This isn't ready for review/merge (I don't like the implementation), but I'm opening a pull request for discussion purposes & so I don't lose track of it.
The problem with this implementation is that it's too specific to JOINs. Instead, there should be a common function that is used wherever a table name can be used, that can also take a SQL statement and render it as a subquery.
I'm also not so sure about the API of putting
.as()on the statement itself... perhaps that is the best place, but it's a bit ambiguous whether that's where you land if you're trying to follow SQL as closely as possible... i could imagine someone expecting it to be an argument to .join() or a method on the outer query... similar to.join().on(), it could be.join().as().on(). Anyway, it's worth thinking about.