I might have identified the first blocker: I am using sql identifier as parameters for table name and column name (not character literals), which is already how current TUMBLE works as current TUMBLE accepts an identifier as the first parameter to specify the TIMESTAMP column.
During planner validation(after query parsing), there is a step to qualify identifiers of parameters from SqlCall (the stack eventually goes into DelegatingScope.java#L224 <https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/DelegatingScope.java#L224>), and sql identifier there is treated as column name by default. Therefore it seems that we need a way to allow sql identifier be qualified as a table name (is there a better idea?). Note that I wrote a unit test in PlannerTest to identify blockers from parser to logical plan generation. -Rui On Fri, Sep 6, 2019 at 9:23 AM Julian Hyde <jhyde.apa...@gmail.com> wrote: > To be pedantic. Note that “strings” in SQL are called character literals > and are enclosed in single-quotes. > > My example also used named parameters. These used quoted identifiers. SQL > identifiers are enclosed in double-quotes. > > Julian > > > On Sep 5, 2019, at 22:25, Rui Wang <ruw...@google.com.invalid> wrote: > > > > I see. I think you are directing to using STRING for the table and > > descriptor parameters. > > > > If so I think it's a good idea to do prototyping. I am digging into > > implementation to prototype a version of "TABLE(TUMBLE("table_name", > > "column_name", INTERVAL))" now. > > > > > > -Rui > > > >> On Wed, Sep 4, 2019 at 8:03 PM Julian Hyde <jh...@apache.org> wrote: > >> > >> Maybe they’re keywords? If so does it help to include them in > >> double-quotes? e.g. > >> > >> myFun(“TABLE” => ’myTable’, > >> “DESCRIPTOR” => ‘myDescriptor’) > >> > >> Julian > >> > >>> On Aug 29, 2019, at 7:46 PM, Rui Wang <ruw...@google.com.INVALID> > wrote: > >>> > >>> And I think both TABLE and DESCRIPTOR are not supported as > >> (table)function > >>> parameters? > >>> > >>> TABLE parameter: TABLE(table_name) or TABLE table_name to specify an > >>> input table. > >>> DESCRIPTOR parameter: DESCRIPTOR(column_name, ...) to specify columns > >> from > >>> the input table. > >>> > >>> > >>> -Rui > >>> > >>> > >>>> On Thu, Aug 29, 2019 at 3:24 PM Rui Wang <ruw...@google.com> wrote: > >>>> > >>>> Thanks Julian for your explanation and the pointer. > >>>> > >>>> I will go to the direction of TABLE(Function) syntax then. > >>>> > >>>> > >>>> -Rui > >>>> > >>>>> On Thu, Aug 29, 2019 at 3:03 PM Julian Hyde <jh...@apache.org> > wrote: > >>>>> > >>>>> Standard SQL doesn’t allow functions in the FROM clause. I think it’s > >>>>> because tables and functions are in different namespaces (and > therefore > >>>>> there could be a table and a function with the same name). So you > need > >> to > >>>>> use the TABLE keyword to indicate that you are using a function as a > >> table. > >>>>> > >>>>> This has been discussed before; see > >>>>> > >> > https://issues.apache.org/jira/browse/CALCITE-1472?focusedCommentId=15662182&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-15662182 > >>>>> < > >>>>> > >> > https://issues.apache.org/jira/browse/CALCITE-1472?focusedCommentId=15662182&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15662182 > >>>>>> . > >>>>> > >>>>>> On Aug 29, 2019, at 2:37 PM, Rui Wang <ruw...@google.com.INVALID> > >>>>> wrote: > >>>>>> > >>>>>> Hi Community, > >>>>>> > >>>>>> I have been searching and trying Calcite's query syntax to match > >>>>>> CALCITE-3272 <https://jira.apache.org/jira/browse/CALCITE-3272> > >> (TUBME > >>>>> as a > >>>>>> table function call). > >>>>>> > >>>>>> Currently, the closest syntax in Calcite I found is: > >>>>>> > >>>>>> FROM TABLE(TUMBLE(params...)) > >>>>>> > >>>>>> The better syntax should be: > >>>>>> > >>>>>> FROM TUMBLE(params..), which basically is the form of FROM > >>>>>> table_function_name(params...). > >>>>>> > >>>>>> > >>>>>> > >>>>>> Is the second option already supported by Calcite? if not, would it > be > >>>>>> better to go to support it? > >>>>>> > >>>>>> > >>>>>> -Rui > >>>>> > >>>>> > >> > >> >
