I will certainly ask. I noticed that most members are big vendors, but that might have to do with a $2200 membership fee.
It would probably be good to have ASF represented more broadly by the projects that use SQL as an API. On Thursday, April 19, 2018, Julian Hyde <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 > >>>> [email protected] > >>>> > >>>> 2018-04-18 21:31 GMT-04:00 Julian Hyde <[email protected]>: > >>>> > >>>>> 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 <[email protected]> > 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 > >>>>>> [email protected] > >>>>>> > >>>>>> 2018-04-18 17:00 GMT-04:00 Julian Hyde <[email protected]>: > >>>>>> > >>>>>>> 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 > >>>>>>> > >>>>>>> > >>>>> > >>>>> > >>>> > >> > >> > >
