Thanks for the clarifications. I see, that makes sense. I've had similar ideas in the past for different reasons. The jOOQ diagnostics feature set is a prototype where we will analyse (and for that: normalise) SQL to a more standardised set of features and syntaxes. One reason why we want to do this is to detect duplicate, or "similar" SQL to reduce the load on execution plan caches and the planner in general: https://www.jooq.org/doc/latest/manual/sql-execution/diagnostics/
This is not very advanced yet, but very promising. So, given that the features you're looking for, and what we've already started doing overlap to some extent, I'm positive we can add much more value in this area in the future. Thanks, Lukas On Mon, Jun 22, 2020 at 8:16 PM Ryan Wisnesky <[email protected]> wrote: > The short answer to your question is that we’re doing static analysis of > SQL queries, trying to prove that they have certain properties via > automated techniques. As such, these transformations are not so much > cosmetic as part of a normalization pipeline to construct first order logic > from SQL; at no point do we ever run any SQL. Really what I’m looking for > is an SQL -> relational algebra translator that is as complete as is > theoretically possible, and JOOQ seems pretty close. > > On Jun 22, 2020, at 11:09 AM, Lukas Eder <[email protected]> wrote: > > > > On Mon, Jun 22, 2020 at 7:31 PM Ryan Wisnesky <[email protected]> wrote: > >> What's the use case of this transformation? >> >> >> I’m trying to use JOOQ as a “universal parser” for a very simple >> select/from/where fragment of SQL with a simple abstract syntax, but across >> a bunch of vendors at once. But perhaps this is the same problem as the >> problem above - how to insert new variables in from clauses. >> > > But jOOQ's out of the box parser / renderer can already do that. It can > parse this simple syntax (or even more complex syntax), and then transform > it to whatever dialect is currently supported. You seem to want to have > some (cosmetic?) transformations in the generated SQL, which are out of > scope for what jOOQ can do right now. Of course, we can add these things > eventually, but they will take time to implement. > > My question here is less related to the question *what* you want to > achieve, but to the *why*. Why do you think ANSI joins work less well? Why > do you think all columns have to be qualified? Why do you prefer all tables > to be aliased? Without understanding the "whys", I don't think I can > provide you with the best possible "hows"... > > Lukas > > -- > You received this message because you are subscribed to a topic in the > Google Groups "jOOQ User Group" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/jooq-user/VKee0sUdG-w/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jooq-user/CAB4ELO6xsCzem48B0FkXoR%3D8KL41drZBf1sN_PiGjvyL9DKFhQ%40mail.gmail.com > <https://groups.google.com/d/msgid/jooq-user/CAB4ELO6xsCzem48B0FkXoR%3D8KL41drZBf1sN_PiGjvyL9DKFhQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > > -- > You received this message because you are subscribed to the Google Groups > "jOOQ User Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jooq-user/86158B01-29C1-47FF-A100-77F91EF40D6F%40conexus.com > <https://groups.google.com/d/msgid/jooq-user/86158B01-29C1-47FF-A100-77F91EF40D6F%40conexus.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jooq-user/CAB4ELO4XX2pfiM2NHMZZhC23-V4TqnKBgdwVM3Y80vh0KpnF9w%40mail.gmail.com.
