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 >>>>> >>>>> >>> >>> >>
