I see this as functionality for the Babel parser, not the core parser, because it helps with compatibility but adds no expressive power.
No one has yet explained why this syntax was introduced into those engines that have it, eg postgres. It wasn’t “historical reasons” for them. Just curious. > On Jun 12, 2019, at 12:12 AM, Andrew O <[email protected]> wrote: > > Translating could work for my use case, although it may be counter to some > of the other recent discussions where the bias was to keep the parser just > doing parsing and no more (so translation would need to happen in another > step?). > > (and Yes, as you suggest, essentially this trying to parse valid Postgres > SQL) > > Thanks > > Andrew > >> On Tue, 11 Jun 2019, 23:03 Haisheng Yuan, <[email protected]> wrote: >> For historical reasons, perhaps. We need to parse and translate into CREATE >> TABLE AS SELECT... if we are going to support this syntax for Postgres and >> SQL Server. >> >> - Haisheng >> >> ------------------------------------------------------------------ >> 发件人：Julian Hyde<[email protected]> >> 日 期：2019年06月12日 05:41:38 >> 收件人：<[email protected]> >> 主 题：Re: Select into Temporary Table >> >> I’ve never understood why some SQL dialects have “SELECT ... INTO table”. >> What’s wrong with “INSERT INTO table SELECT ...”? >> >> Julian >> >> > On Jun 11, 2019, at 1:27 PM, Andrew O <[email protected]> wrote: >> > >> > Does / should Calcite support select into expressions? E.g. I'm using v1.19 >> > with queries of the style: >> > >> > select * into temporary table "#myTempResults" from (select colA >> > from my Table where colA = 'abc') >> > >> > but these queries fail to parse at the "into" words in the expression. (I >> > have a calcite connection setup with SqlDdlParserImpl) >> > >> > Assuming this isn't currently supported, is this something that is in the >> > scope of the default Calcite code, or something that would need to be a >> > custom extension? >> > >> > I do see in Schema.TableType there is an enum value of TEMPORARY_TABLE, but >> > I have found where us this set / used. >> > >> > Also, as additional context >> > - my target DB for the queries is Postgres (so supports this SQL query >> > directly) >> > - also in the future I would like to support parsing / processing Cursor >> > related operations (e.g. Declare Cursor, fetch next, fetch next, etc.). >> > Although I'm sure if / where these would belong in Calcite. >> > >> > Thanks in advance >> > >> > Andrew
