I’ve actually joined the standard to be, in addition to representing my lab, an advocate for Calcite and ASF, so I could represent these needs, and bring anything else up.
Just let me know. Thank you, Edmon On Thursday, April 19, 2018, Julian Hyde <jh...@apache.org> wrote: > I’d love to know whether/when you guys intend to standardize streaming SQL. > > I have come to the conclusion that extensions to SQL’s existing temporal > support (i.e. being able to join each row to a different temporal snapshot > of a table) would be extremely useful to support streaming. > > Also, extensions to handle weakly typed relations (think of javascript and > ruby’s type systems as opposed to java’s) would be welcome. > > And support for approximations, e.g. > > select count(distinct x) approximate (within 1 percent) from t; > > Julian > > > > > On Apr 19, 2018, at 11:40 AM, Edmon Begoli <ebeg...@gmail.com> wrote: > > > > I am on the SQL standards committee and I will ask. > > > > Are there any other things anyone would like to know? > > > > On Thu, Apr 19, 2018 at 5:54 PM Michael Mior <mm...@uwaterloo.ca> wrote: > > > >> Thanks for the review. I have most of these changes sorted out. Is there > >> any good resource for the SQL standard aside from purchasing a copy of > the > >> standard itself. If not, do you think that this is something the ASF > would > >> be willing to do? Assuming it could be shared between projects, I think > >> there are many who would benefit from this. > >> > >> -- > >> Michael Mior > >> mm...@uwaterloo.ca > >> > >> 2018-04-18 21:31 GMT-04:00 Julian Hyde <jh...@apache.org>: > >> > >>> A couple of minor things. Your isJson function should return boolean > not > >>> Boolean, because the ISJSON function is strict - i.e. returns unknown > if > >>> and only if its input is null. If the input is null the code generator > >> will > >>> not call it. > >>> > >>> I think SqlIsJsonFunction is probably not necessary. I think everything > >>> about the function can be deduced by reflection. (That’s how the Geo > >>> functions work, also.) > >>> > >>> I’d add tests for JSON functions to SqlOperatorBaseTest rather than > >>> creating CalciteJsonOperatorTest and JsonOperatorBaseTest. JSON > functions > >>> are not that different from the built-in function set. (The Geo > functions > >>> are not in the SQL standard; that’s why I separated them a bit.) > >>> > >>> Julian > >>> > >>> > >>>> On Apr 18, 2018, at 5:59 PM, Michael Mior <mm...@uwaterloo.ca> wrote: > >>>> > >>>> Thanks Julian! I opened CALCITE-2266 to track implementing some of the > >>> new > >>>> JSON functions. I took a stab at implementing ISJSON in the following > >>>> commit: > >>>> > >>>> https://github.com/michaelmior/calcite/commit/ > >>> d6930fcd04ed83d37f56a7795ee794 > >>>> 1b521fb99c > >>>> > >>>> These are touching parts of the code base I'm unfamiliar with so I > >> mostly > >>>> don't know what I'm doing :) I added a new operator table which I'm > >>>> guessing we probably don't want to do but it made it easier for me > when > >>>> testing to isolate the new code. > >>>> > >>>> -- > >>>> Michael Mior > >>>> mm...@uwaterloo.ca > >>>> > >>>> 2018-04-18 17:00 GMT-04:00 Julian Hyde <jh...@apache.org>: > >>>> > >>>>> Somehow I missed it, but a new version of the SQL standard was > >> released > >>> in > >>>>> December 2016. Here is wikipedia’s description of the new features: > >>>>> > >>>>>> SQL:2016 introduced 44 new optional features. 22 of them belong > >>>>>> to the JSON functionality, ten more are related to polymorphic table > >>>>>> functions. The additions to the standard include: > >>>>>> > >>>>>> * JSON: Functions to create JSON documents, to access parts of > >>>>>> JSON documents and to check whether a string contains valid > >>>>>> JSON data > >>>>>> * Row Pattern Recognition: Matching a sequence of rows against > >>>>>> a regular expression pattern > >>>>>> * Date and time formatting and parsing > >>>>>> * LISTAGG: A function to transform values from a group of rows into > a > >>>>>> delimited string > >>>>>> * Polymorphic table functions: table functions without predefined > >>> return > >>>>> type > >>>>>> * New data type DECFLOAT > >>>>> > >>>>> Nothing earth-shattering, but some good stuff there. DECFLOAT makes a > >>> lot > >>>>> of sense — businesses hate the kind of rounding errors that binary > >>> floating > >>>>> point introduces, and DECFLOAT would seem to map directly to java’s > >>>>> BigDecimal. > >>>>> > >>>>> And MATCH_RECOGNIZE, which we have already started work on. > >>>>> > >>>>> Julian > >>>>> > >>>>> > >>> > >>> > >> > >
