Do you think you could help bring a little more openness to the process? I’d love to know what areas are being considered, and what is the target date for the next standard.
Even if the information flow is only one way, it would help counter some perceptions that the process is dominated by the large vendors. Julian > On Apr 19, 2018, at 1:21 PM, Edmon Begoli <ebeg...@gmail.com> wrote: > > 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 >>>>>>> >>>>>>> >>>>> >>>>> >>>> >> >>
