Very cool! Interesting approach. It is kind of like create external table as a sub clause of the query.
My question would be why it isn't just done in the select list. I'm generally against adding constructs and new clauses in the parser, especially with repetitive information. We choose to use the existing CONVERT_FROM from sql to solve the datatype problem. It's a bit verbose but avoids introducing new concepts to existing sql. To simplify it, I've considered the other casting form which I believe is similar to the Java casting prefix. It would then be: SELECT (varchar) col1 FROM t1 This doesn't distinguish between dynamic and existing columns. We've shown that you don't need to do that but that is pretty complicated to do. If you wanted to avoid that, maybe you could prefix the type. So a mix of dynamic and known might look like this : SELECT (?varchar) col1, col2 FROM t1 That being said, I've worked with the parser and can guess the pain of trying to add it as optional to the existing select list parsing. Especially given scalar sub queries. If merged (even in parser definition files) I would definitely want it to be optional as it is. That namespace is already cluttered and I think we should only merge new language features into core if they are sql spec or already used by the majority of projects. What about a language features contrib module? All in all, very nice work James etc al. On Dec 4, 2014 4:25 AM, "Ted Dunning" <[email protected]> wrote: > Might make an interesting alternative, but I don't think that it suffices > for all needs. In particular, there are definitely times when I don't know > what columns to declare. > > > > On Wed, Dec 3, 2014 at 1:44 PM, Julian Hyde <[email protected]> wrote: > > > Phoenix has a neat extension to SQL for declaring dynamic columns as > > part of a query. This is for columns that are present in the > > schema-less table but we didn’t declare them when we issued the CREATE > > TABLE statement. > > > > http://phoenix.apache.org/dynamic_columns.html > > > > James Taylor is proposing adding it to Calcite’s SQL: > > https://issues.apache.org/jira/browse/CALCITE-493 > > > > Drill developers, Would this be a useful syntax extension for Drill? I > > think it has some advantages over Drill's implicit, type-less columns. > > > > Julian > > >
