+1 to Julian. There are open questions on supporting UNION (instead of UNION ALL), aggregation and negation through recursion. Many of those topics still have papers written to address their open questions until today. I think the PR is geared towards addressing the UNION ALL case, and extending the architecture to cover the more involved cases may be tricky if we commit to the UNION ALL friendly approach.
Thanks, Walaa. On Thu, Apr 4, 2019 at 11:23 AM Julian Hyde <[email protected]> wrote: > > I guess my concerns would all be met if we could flag this as “experimental”. > > There are more general forms of recursive / deductive queries that I would > like us to be able to tackle someday. If and when we do, I don’t want to be > locked into the structures and nomenclature of this change. But until then, > this change is a huge step forward. If the APIs were labeled “experimental > and subject to change without notice” then we can evolve as we know more. > > By the way, I have personal project where I am experimenting with melding > functional programming with relational algebra. If you have > functions-as-values in relational algebra then you can add a fixed-point > operator and thereby create recursive/deductive queries. You can use > higher-order functions such as map and filter on nested collections, and > exploit the fact that the relational operators (project, filter, join) are > themselves higher-order functions. Rather than adding functional extensions > to a relational language, I started digging the tunnel from the other end: I > started with a small, elegant functional language (ML), wrote an interpreter > in Java, and am extending the language for relational algebra. If all goes > well, there would be some extensions in Calcite’s algebra for > functions-as-values and relational expressions that are defined by (possibly > recursive) functions. > > Julian > > [1] https://github.com/julianhyde/smlj <https://github.com/julianhyde/smlj> > > > > On Apr 4, 2019, at 9:31 AM, Stamatis Zampetakis <[email protected]> wrote: > > > > Hello, > > > > The issue has advanced quite a lot and I guess it will be finalised soon. > > There is some ongoing discussion about a few naming/refactorings in the PR > > [1] but these could be resolved easily. > > > > Ruben, had made a proposal which LGTM so I am inclined to merge the PR as > > soon as the last changes are made (and no other serious issues appear). > > > > I guess it is the right time to jump in to the discusion, especially if you > > strongly disagree on the general approach. > > > > [1] https://github.com/apache/calcite/pull/1020 > > > > Best, > > Stamatis >
