I should have given more context but I think Julian's response is similar
and close to (if not just the same as) what I faced.
I tried
"select * FROM TABLE(TUMBLE_TVF(ORDERS, ROWTIME, INTERVAL '10' MINUTE))"
named parameters, TABLE ORDERS, TABLE(ORDERS), DESCRIPTOR(ROWTIME),
etc. were not included to not introduce too much complex at the
beginning. I also use TUMBLE_TVF for prototyping to skip existing
TUMBLE implementation.
By doing so I ended with column "ORDERS" is not found in validator in
the current scope.
But based on the response sounds like TABLE(ORDERS) or TABLE ORDERS
and DESCRIPTOR(ROWTIME) is designed to be able to pass validator, at
least the namespace validationstep.
The next step of mine should go directly to see how to make the
following work at least by passing validator:
SELECT *
FROM TABLE(TUMBLE_TVF(
TABLE ORDERS, // or could be TABLE(ORDERS)
DESCRIPTOR(ROWTIME),
INTERVAL '10' MINUTE))
named parameters should not be required at this moment but please
correct me if I am wrong.
-Rui
On Tue, Sep 10, 2019 at 2:24 PM Julian Hyde <[email protected]> wrote:
> Are you referring to problems parsing this:
>
> SELECT *
> FROM Tumble (
> data => TABLE Bid ,
> timecol => DESCRIPTOR ( bidtime ) ,
> dur => INTERVAL '10' MINUTES ,
> offset => INTERVAL '0' MINUTES );
>
> If so I can see how "TABLE Bid” and "DESCRIPTOR ( bidtime ) “ might cause
> the validator problems. The validator will look for a column called
> “bidtime”. We would need a way to tell the validator to treat “bidtime” as
> an identifier but not to expect it to exist in the current scope. The
> intent of DESCRIPTOR is to tell the validator to suspend the usual rules of
> validation.
>
> I’m not quite sure why the paper author (probably Tyler Akidau) decided to
> use the DESCRIPTOR keyword, and whether there are any SQL dialects where
> this syntax is valid. If anyone has anything to say for or against using
> DESCRIPTOR I’d like to hear it, but let’s stick with DESCRIPTOR for now.
>
> Julian
>
>
> > On Sep 10, 2019, at 11:15 AM, Rui Wang <[email protected]>
> wrote:
> >
> > 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 <[email protected]>
> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]>
> >> 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 <[email protected]> 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 <[email protected]>
> >> 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 <[email protected]>
> >>>>>>> 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
> >>>>>>>
> >>>>>>>
> >>>>
> >>>>
> >>
>
>
