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 <[email protected]> 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 < > [email protected]> 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 >> >
