Unions and parentheses are a huge can of worms across all the 25 currently supported dialects in jOOQ. By default, we better play safe and add some additional syntax that mostly doesn't hurt, rather than leaving it away, and then run into tons of edge cases.
The H2 issues you've linked are edge cases already in H2, and there's probably a workaround (we might help with that, if we can see the actual query). We have a lot of integration tests testing a variety of combinations of operators against all of those 25 dialects, and the syntax that is currently being generated by jOOQ is the one that fails the least amount of integration tests. As you can see, I've been involved with one of the issues you've linked (
https://github.com/h2database/h2database/issues/918) as our integration tests test the weirdest kind of SQL that might even help discover bugs in various database products.
Having said so, in the future, we want to be more sophisticated with the SQL we generate, and avoid generating unnecessary parentheses (this also affects boolean value expressions, for example). But for that, we need a lot more integration tests and a lot better internal query model that allows for better transformations / introspections, etc.
In the case of parenthesised union subqueries, at least these things need to be considered:
- Are there only unions (single operator type, no precedence issues), or also union all?
- Are there only unions or also exceptions / intersections?
- Do union subqueries contain order by / limit / offset
- Do union subqueries contain with?
- Do union subqueries contain other set operators like union?
- Is the query a top level query or a derived table or a correlated subquery or something else?
"Just" removing the parentheses will definitely break some tests in some databases, so we'd have to figure out when exactly they can be removed on which dialect.
And that's currently not a priority, I'm afraid.
Thanks,
Lukas