Hello, @Julian: It looks like an interesting project, looking forward to see what comes out of it.
@Walaa: The current implementation takes care of UNION ALL but it seems relatively easy to extend it for UNION. At least with a naive implementation. Research-wise, I am not very familiar with the domain so if you could share a few papers it would be nice :) @Ruben: Thanks for the changes and great work so far. I will have a look when I find some time. Best, Stamatis On Fri, Apr 5, 2019 at 3:48 PM Ruben Q L <[email protected]> wrote: > Thanks for the feedback. > I have pushed <https://github.com/apache/calcite/pull/1020> the latest > modifications. As requested, I have flagged all new features as > "experimental". > > Best regards, > Ruben > > > Le jeu. 4 avr. 2019 à 20:29, Walaa Eldin Moustafa <[email protected]> > a > écrit : > > > +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 > > > > > >
