Yes. Apache has representation in the W3C and Open Geospatial Consortium. Much database innovation these days is coming out of open source, and these open source projects tend to join Apache, so it makes a lot of sense that we have a voice.
> On Apr 19, 2018, at 1:30 PM, Edmon Begoli <[email protected]> wrote: > > 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 >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>> >>>> >> >>
