Re: BindableTableScan is losing aliased named

Il ven 17 nov 2017, 22:36 Julian Hyde ha scritto: > Translating to RelNode loses some metadata. When preparing a SQL > statement, we use the column names and types given to us by the > validator for use by ResultSetMetaData. > > There's a related interesting case where a column

Re: BindableTableScan is losing aliased named

Translating to RelNode loses some metadata. When preparing a SQL statement, we use the column names and types given to us by the validator for use by ResultSetMetaData. There's a related interesting case where a column appears in ORDER BY but not SELECT. For example, "SELECT x FROM t ORDER BY x,

[jira] [Created] (CALCITE-2060) connection.getMetaData().getTypeInfo();

Sergio Sainz created CALCITE-2060: - Summary: connection.getMetaData().getTypeInfo(); Key: CALCITE-2060 URL: https://issues.apache.org/jira/browse/CALCITE-2060 Project: Calcite Issue Type:

Re: BindableTableScan is losing aliased named

Il ven 17 nov 2017, 19:19 Julian Hyde ha scritto: > > IMHO It would better to keep somethin like an EnumerableProjection which > > renames the fields > > I disagree. If we commit to preserving field names all kinds of > optimization are not possible. > > In Calcite RelNode

Re: Columns with name "value"

Il ven 17 nov 2017, 18:59 Michael Mior ha scritto: > You could certainly do this by modifying the parser to remove sequence > expressions (where the VALUE keyword is used) if you don't need them. > However, this wouldn't be something I would recommend and not something >

Re: Support for "limit ?"

Parameters in the OFFSET and FETCH clauses are definitely a feature we'd like. It's moderate effort. It's not been done just because we don't have the resources. Can you please log a JIRA case. My best "hint" is how I'd approach the problem: I'd add test methods to SqlParserTest,

Re: BindableTableScan is losing aliased named

> IMHO It would better to keep somethin like an EnumerableProjection which > renames the fields I disagree. If we commit to preserving field names all kinds of optimization are not possible. In Calcite RelNode world, field names are a hint to make debugging easier but are not ultimately

Re: BindableTableScan is losing aliased named

your test is working I will try to understand where is the problem in my code b.q. I am looking for a sponsor for this patch, which is a real blocker for me, could you pleas take a look Luis ? https://github.com/apache/calcite/pull/568 Thank you Enrico 2017-11-17 17:45 GMT+01:00 Luis Fernando

Re: BindableTableScan is losing aliased named

Please insert the following test in ScannableTableTest and run:   /** ProjectableFilterableTable project push down using alias. */   @Test public void testPFPushDownWithAlias() throws Exception {     final StringBuilder buf = new StringBuilder();     final Table table = new

Re: BindableTableScan is losing aliased named

In the RowType I have 'k1' and not "thekey" Enrico 2017-11-17 17:20 GMT+01:00 Luis Fernando Kauer : > Did you execute the query? > ProjectRemoveRule removes the Project when it is "trivial". Since the > only used project was pushed to BindableTableScan, the

Re: BindableTableScan is losing aliased named

Did you execute the query? ProjectRemoveRule removes the Project when it is "trivial".  Since the only used project was pushed to BindableTableScan, the Project would only set the alias, but that can be done in row type. The result is correct because RowType is preserved with the alias.  It

BindableTableScan is losing aliased named

Hi, I have a ProjectableFilterableTable, it seems to me that the BindablaScan RelNode does not keep track of column name aliases in the original projection Example: Query:SELECT k1 theKey FROM tblspace1.tsql where k1 ='mykey2' -- Logical Plan LogicalProject(THEKEY=[$0])

Support for "limit ?"

Hi, I see that Calcite does not support dynamic parameters in LIMIT clause. Is it only a simple feature to be implemented or there is a deep reason ? I see that limit offset and fetch are already represented with RexNode in EnumerableLimit If it is feasible can you give me some hint in order to

[jira] [Created] (CALCITE-2059) Apache Geode adapter

Christian Tzolov created CALCITE-2059: - Summary: Apache Geode adapter Key: CALCITE-2059 URL: https://issues.apache.org/jira/browse/CALCITE-2059 Project: Calcite Issue Type: New Feature

Re: Parser error on trivial JDBC update

I tried to solve the problem this is my proposal https://github.com/apache/calcite/pull/568 I think this partly resolves CALCITE-1708or at least one test case marked with that issue now is working. But I did not drop the @Ignore annotation 2017-11-17 8:59 GMT+01:00 Enrico Olivelli

Re: Columns with name "value"

I see, but unfortunately MySQL allows such id. Do you think it is not possible at all to add a flag to allow it? Enrico Il ven 17 nov 2017, 02:02 Julian Hyde ha scritto: > No, it isn’t possible. VALUE is a reserved keyword in Calcite and in > standard SQL. > > Either quote it