You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@iotdb.apache.org by Abdelrahman Mostafa <ab...@gmail.com> on 2026/03/24 22:18:02 UTC

[DISCUSS] Add FROM-First-syntax support to IoTDB Table Mode

Hi all,

I would like to propose adding support for FROM-first syntax to IoTDB's
Table SQL dialect.

*This feature improves the user experience in the following ways:*

   - Better IDE/CLI auto-completion: The IDE knows the table schema before
   the SELECT clause, enabling intelligent column suggestions
   - Logical flow alignment: FROM-first syntax aligns better with the
   actual execution order, and the human thought process defines the source
   first, then filter, then project
   - Quick data exploration: Instead of writing SELECT * FROM sensors, you
   simply write FROM sensors

For more details, please refer to the GitHub issue:
https://github.com/apache/iotdb/issues/17336

*Proposed Syntax:*
Add a new grammar rule to RelationalSql.g4:

fromFirstQuerySpecification
    : FROM relation (',' relation)*
      (SELECT setQuantifier? selectItem (',' selectItem)*)?
      (WHERE where=booleanExpression)?
      (GROUP BY groupBy)?
      (HAVING having=booleanExpression)?
      (WINDOW windowDefinition (',' windowDefinition)*)?
    ;

Add the new rule as an alternative to queryPrimary:

queryPrimary
    : querySpecification                   #queryPrimaryDefault
    | TABLE qualifiedName                  #table
    | VALUES expression (',' expression)*  #inlineTable
    | '(' queryNoWith ')'                  #subquery
    | fromFirstQuerySpecification          #fromFirstQuery    // NEW
    ;

*Usage Examples:*

-- Current syntax

SELECT temperature, humidity FROM sensors WHERE time >= 10;

-- Proposed FROM-first syntax

 FROM sensors SELECT temperature, humidity WHERE time >= 10;

-- Quick exploration (omitting SELECT implies SELECT *)

FROM sensors LIMIT 10;

*Implementation Approach:*

   1. Grammar Update: Add fromFirstQuerySpecification rule to
   RelationalSql.g4
   2. AST Builder: Add visitFromFirstQuerySpecification() in
   AstBuilder.java, reusing the existing visitQuerySpecification() logic with
   added handling for the omitted SELECT clause implying SELECT *
   3. Testing: Add integration tests covering all new syntax scenarios
   4. Documentation: Update IoTDB docs with usage examples and sample use
   cases

*Note:* This is an additive feature for Table mode only; the traditional
SELECT ... FROM ... syntax will remain fully supported.

I will begin implementation once the community confirms the design.
My GitHub handle is @Abdelrahman-358 if you would like to assign the issue
to me.

Any feedback or comments are welcome.

Best regards,
Abdelrahman

Re: [DISCUSS] Add FROM-First-syntax support to IoTDB Table Mode

Posted by Yuan Tian <ja...@gmail.com>.
Hi Abdelrahman,

The vote usually lasts for 72 hours.

Best regards,

Yuan


On Wed, Mar 25, 2026 at 10:28 PM Abdelrahman Mostafa <
abdo.mostafa.dev@gmail.com> wrote:

> Hi Yuan,
>
> Thank you for the feedback and guidance.
>
> Regarding the clause ordering, my preference is to follow `FROM relation
> SELECT ... WHERE ...` for the following reasons:
>
>    - It simply moves the FROM clause to the front of a traditional SQL
>    statement without changing the familiar structure of the rest of the
> query.
>    This makes the feature intuitive from day one.
>    - It still provides the intended benefits, including improved IDE/CLI
>    auto-completion and faster data exploration.
>    - Aligning with the approach used in DuckDB helps maintain consistency
>    with an existing implementation, reducing the learning curve and
> avoiding
>    introducing a completely new clause ordering.
>
> As you suggested, I will initiate a vote on the mailing list to gather the
> community's preference on whether SELECT or WHERE should come first.
> Also, how long would you recommend keeping the vote open?
>
> Best regards,
> Abdelrahman
>

Re: [DISCUSS] Add FROM-First-syntax support to IoTDB Table Mode

Posted by Abdelrahman Mostafa <ab...@gmail.com>.
Hi Yuan,

Thank you for the feedback and guidance.

Regarding the clause ordering, my preference is to follow `FROM relation
SELECT ... WHERE ...` for the following reasons:

   - It simply moves the FROM clause to the front of a traditional SQL
   statement without changing the familiar structure of the rest of the query.
   This makes the feature intuitive from day one.
   - It still provides the intended benefits, including improved IDE/CLI
   auto-completion and faster data exploration.
   - Aligning with the approach used in DuckDB helps maintain consistency
   with an existing implementation, reducing the learning curve and avoiding
   introducing a completely new clause ordering.

As you suggested, I will initiate a vote on the mailing list to gather the
community's preference on whether SELECT or WHERE should come first.
Also, how long would you recommend keeping the vote open?

Best regards,
Abdelrahman

Re: [DISCUSS] Add FROM-First-syntax support to IoTDB Table Mode

Posted by Yuan Tian <ja...@gmail.com>.
Alternatively, you could *initiate a vote* via email to see everyone's
preference on whether *WHERE* or *SELECT* should come first. The community
is open, and we will ultimately *abide by the majority's decision*.

On Wed, Mar 25, 2026 at 8:49 AM Yuan Tian <ja...@gmail.com> wrote:

> Hi Abdelrahman,
>
> Thank you for the detailed proposal and for taking the initiative on this.
> I really appreciate your work here. Adding FROM-first syntax is an
> excellent idea, and I completely agree with the benefits you mentioned—it
> will definitely improve the developer experience, especially for IDE
> auto-completion and quick data exploration.
>
> The overall implementation approach looks very solid, and I have no issues
> with the rest of the design. I only have one point I'd like to discuss
> regarding the proposed grammar rule: the relative order of the SELECT and
> WHERE clauses.
>
> In your proposed syntax, the order is: FROM relation SELECT ... WHERE ...
>
> From the perspective of relational algebra and the actual execution
> pipeline, the WHERE clause (filtering) is applied before the SELECT
> clause (projection). If one of our goals is to align the syntax with the
> logical execution flow, would it make more sense to place WHERE before
> SELECT (i.e., FROM relation WHERE ... SELECT ...)?
>
> I noticed that DuckDB's FROM-first syntax keeps SELECT before WHERE (FROM
> ... SELECT ... WHERE ...), essentially just moving the FROM clause to the
> front of a traditional SQL statement. While sticking to DuckDB's style
> might feel more familiar to users migrating from other systems, strictly
> following the execution order might be more intuitive for a modern dialect.
>
> What are your thoughts on this? Should we strictly follow the execution
> order, or align with the DuckDB approach for familiarity?
>
> Everything else looks perfect. Once we align on this detail, I'd be happy
> to assign the issue to you so you can begin the implementation.
>
>
> Best regards,
>
> Yuan
>
> On Wed, Mar 25, 2026 at 6:18 AM Abdelrahman Mostafa <
> abdo.mostafa.dev@gmail.com> wrote:
>
>> Hi all,
>>
>> I would like to propose adding support for FROM-first syntax to IoTDB's
>> Table SQL dialect.
>>
>> *This feature improves the user experience in the following ways:*
>>
>>    - Better IDE/CLI auto-completion: The IDE knows the table schema before
>>    the SELECT clause, enabling intelligent column suggestions
>>    - Logical flow alignment: FROM-first syntax aligns better with the
>>    actual execution order, and the human thought process defines the
>> source
>>    first, then filter, then project
>>    - Quick data exploration: Instead of writing SELECT * FROM sensors, you
>>    simply write FROM sensors
>>
>> For more details, please refer to the GitHub issue:
>> https://github.com/apache/iotdb/issues/17336
>>
>> *Proposed Syntax:*
>> Add a new grammar rule to RelationalSql.g4:
>>
>> fromFirstQuerySpecification
>>     : FROM relation (',' relation)*
>>       (SELECT setQuantifier? selectItem (',' selectItem)*)?
>>       (WHERE where=booleanExpression)?
>>       (GROUP BY groupBy)?
>>       (HAVING having=booleanExpression)?
>>       (WINDOW windowDefinition (',' windowDefinition)*)?
>>     ;
>>
>> Add the new rule as an alternative to queryPrimary:
>>
>> queryPrimary
>>     : querySpecification                   #queryPrimaryDefault
>>     | TABLE qualifiedName                  #table
>>     | VALUES expression (',' expression)*  #inlineTable
>>     | '(' queryNoWith ')'                  #subquery
>>     | fromFirstQuerySpecification          #fromFirstQuery    // NEW
>>     ;
>>
>> *Usage Examples:*
>>
>> -- Current syntax
>>
>> SELECT temperature, humidity FROM sensors WHERE time >= 10;
>>
>> -- Proposed FROM-first syntax
>>
>>  FROM sensors SELECT temperature, humidity WHERE time >= 10;
>>
>> -- Quick exploration (omitting SELECT implies SELECT *)
>>
>> FROM sensors LIMIT 10;
>>
>> *Implementation Approach:*
>>
>>    1. Grammar Update: Add fromFirstQuerySpecification rule to
>>    RelationalSql.g4
>>    2. AST Builder: Add visitFromFirstQuerySpecification() in
>>    AstBuilder.java, reusing the existing visitQuerySpecification() logic
>> with
>>    added handling for the omitted SELECT clause implying SELECT *
>>    3. Testing: Add integration tests covering all new syntax scenarios
>>    4. Documentation: Update IoTDB docs with usage examples and sample use
>>    cases
>>
>> *Note:* This is an additive feature for Table mode only; the traditional
>> SELECT ... FROM ... syntax will remain fully supported.
>>
>> I will begin implementation once the community confirms the design.
>> My GitHub handle is @Abdelrahman-358 if you would like to assign the issue
>> to me.
>>
>> Any feedback or comments are welcome.
>>
>> Best regards,
>> Abdelrahman
>>
>

Re: [DISCUSS] Add FROM-First-syntax support to IoTDB Table Mode

Posted by Yuan Tian <ja...@gmail.com>.
Hi Abdelrahman,

Thank you for the detailed proposal and for taking the initiative on this.
I really appreciate your work here. Adding FROM-first syntax is an
excellent idea, and I completely agree with the benefits you mentioned—it
will definitely improve the developer experience, especially for IDE
auto-completion and quick data exploration.

The overall implementation approach looks very solid, and I have no issues
with the rest of the design. I only have one point I'd like to discuss
regarding the proposed grammar rule: the relative order of the SELECT and
WHERE clauses.

In your proposed syntax, the order is: FROM relation SELECT ... WHERE ...

From the perspective of relational algebra and the actual execution
pipeline, the WHERE clause (filtering) is applied before the SELECT clause
(projection). If one of our goals is to align the syntax with the logical
execution flow, would it make more sense to place WHERE before SELECT
(i.e., FROM relation WHERE ... SELECT ...)?

I noticed that DuckDB's FROM-first syntax keeps SELECT before WHERE (FROM
... SELECT ... WHERE ...), essentially just moving the FROM clause to the
front of a traditional SQL statement. While sticking to DuckDB's style
might feel more familiar to users migrating from other systems, strictly
following the execution order might be more intuitive for a modern dialect.

What are your thoughts on this? Should we strictly follow the execution
order, or align with the DuckDB approach for familiarity?

Everything else looks perfect. Once we align on this detail, I'd be happy
to assign the issue to you so you can begin the implementation.


Best regards,

Yuan

On Wed, Mar 25, 2026 at 6:18 AM Abdelrahman Mostafa <
abdo.mostafa.dev@gmail.com> wrote:

> Hi all,
>
> I would like to propose adding support for FROM-first syntax to IoTDB's
> Table SQL dialect.
>
> *This feature improves the user experience in the following ways:*
>
>    - Better IDE/CLI auto-completion: The IDE knows the table schema before
>    the SELECT clause, enabling intelligent column suggestions
>    - Logical flow alignment: FROM-first syntax aligns better with the
>    actual execution order, and the human thought process defines the source
>    first, then filter, then project
>    - Quick data exploration: Instead of writing SELECT * FROM sensors, you
>    simply write FROM sensors
>
> For more details, please refer to the GitHub issue:
> https://github.com/apache/iotdb/issues/17336
>
> *Proposed Syntax:*
> Add a new grammar rule to RelationalSql.g4:
>
> fromFirstQuerySpecification
>     : FROM relation (',' relation)*
>       (SELECT setQuantifier? selectItem (',' selectItem)*)?
>       (WHERE where=booleanExpression)?
>       (GROUP BY groupBy)?
>       (HAVING having=booleanExpression)?
>       (WINDOW windowDefinition (',' windowDefinition)*)?
>     ;
>
> Add the new rule as an alternative to queryPrimary:
>
> queryPrimary
>     : querySpecification                   #queryPrimaryDefault
>     | TABLE qualifiedName                  #table
>     | VALUES expression (',' expression)*  #inlineTable
>     | '(' queryNoWith ')'                  #subquery
>     | fromFirstQuerySpecification          #fromFirstQuery    // NEW
>     ;
>
> *Usage Examples:*
>
> -- Current syntax
>
> SELECT temperature, humidity FROM sensors WHERE time >= 10;
>
> -- Proposed FROM-first syntax
>
>  FROM sensors SELECT temperature, humidity WHERE time >= 10;
>
> -- Quick exploration (omitting SELECT implies SELECT *)
>
> FROM sensors LIMIT 10;
>
> *Implementation Approach:*
>
>    1. Grammar Update: Add fromFirstQuerySpecification rule to
>    RelationalSql.g4
>    2. AST Builder: Add visitFromFirstQuerySpecification() in
>    AstBuilder.java, reusing the existing visitQuerySpecification() logic
> with
>    added handling for the omitted SELECT clause implying SELECT *
>    3. Testing: Add integration tests covering all new syntax scenarios
>    4. Documentation: Update IoTDB docs with usage examples and sample use
>    cases
>
> *Note:* This is an additive feature for Table mode only; the traditional
> SELECT ... FROM ... syntax will remain fully supported.
>
> I will begin implementation once the community confirms the design.
> My GitHub handle is @Abdelrahman-358 if you would like to assign the issue
> to me.
>
> Any feedback or comments are welcome.
>
> Best regards,
> Abdelrahman
>