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 <ruw...@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 <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
>>>>>>>
>>>>>>>
>>>>
>>>>
>>
