You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by Julian Hyde <jh...@apache.org> on 2019/09/05 03:03:37 UTC
Re: Appropriate query syntax for table-value function windowing (e.g.
CALCITE-3272)
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 <ru...@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 <ru...@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 <ru...@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
>>>
>>>
Re: Appropriate query syntax for table-value function windowing (e.g. CALCITE-3272)
Posted by Rui Wang <ru...@google.com.INVALID>.
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 <jh...@gmail.com> 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 <ru...@google.com.INVALID>
> 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 <jh...@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 <ru...@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 <ru...@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 <ru...@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 <ru...@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
> >>>>>>>
> >>>>>>>
> >>>>
> >>>>
> >>
>
>
Re: Appropriate query syntax for table-value function windowing (e.g.
CALCITE-3272)
Posted by Julian Hyde <jh...@gmail.com>.
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 <ru...@google.com.INVALID> 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 <jh...@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 <ru...@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 <ru...@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 <ru...@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 <ru...@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
>>>>>>>
>>>>>>>
>>>>
>>>>
>>
Re: Appropriate query syntax for table-value function windowing (e.g. CALCITE-3272)
Posted by Rui Wang <ru...@google.com.INVALID>.
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 <jh...@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 <ru...@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 <ru...@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 <ru...@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 <ru...@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
> >>>>>
> >>>>>
> >>
> >>
>
Re: Appropriate query syntax for table-value function windowing (e.g. CALCITE-3272)
Posted by Julian Hyde <jh...@gmail.com>.
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 <ru...@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 <ru...@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 <ru...@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 <ru...@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
>>>>>
>>>>>
>>
>>
Re: Appropriate query syntax for table-value function windowing (e.g. CALCITE-3272)
Posted by Rui Wang <ru...@google.com.INVALID>.
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 <ru...@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 <ru...@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 <ru...@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
> >>>
> >>>
>
>