Re: BindableTableScan is losing aliased named

[Enrico Olivelli]

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 appears in ORDER BY
> but not SELECT. For example, "SELECT x FROM t ORDER BY x, y". The
> RelNode needs to have 2 columns but the ResultSet thinks it only has
> one.
>

I am observing that Calcite tends to add support fields always at the
'right'. Is this a general behaviour or I am lucky and all the plans I am
seeing behave this way ?

I think I will try to capture field names from the SqlNodes, but this will
be feasible if and only if the first N selected RelNodes of the physical
plan represent the first N SqlNodes in the Select clause

Enrico


> Julian
>
>
> On Fri, Nov 17, 2017 at 10:46 AM, Enrico Olivelli 
> wrote:
> > 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 world, field names are a hint to make debugging
> >> easier but are not ultimately reliable. The reliable way to reference
> >> fields is by position.
> >>
> >
> >
> > I understand your point Julian. In my case I want the final resultset to
> > have knowledge of the alias requested by the user.
> >
> > Select a as b from table
> >
> > ResultSet rs = ...
> > String col = rs.getString("b");
> > If I am losing the alias I can't support this case.
> > The test case from Luis is working so there is some trick I am missing
> >
> > Enrico
> >
> >
> >> Julian
> >>
> >>
> >> On Fri, Nov 17, 2017 at 9:33 AM, Enrico Olivelli 
> >> wrote:
> >> > I run the debugger on your test case.
> >> > IMHO The BindableTableScan RelNode does not keep the original aliases
> of
> >> > the query.
> >> > The test cases runs CalciteConnection, maybe there is some magic
> during
> >> the
> >> > execution of the query.
> >> > Can you provide me some insight ?
> >> > Maybe it is better that I provide a reproducer.
> >> > I am not using CalciteConnection but only the planner
> >> >
> >> > Thanks
> >> > Enrico
> >> >
> >> > 2017-11-17 18:08 GMT+01:00 Enrico Olivelli :
> >> >
> >> >> 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 Kauer <
> >> >> lfka...@yahoo.com.br.invalid>:
> >> >>
> >> >>> 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 BeatlesProjectableFilterableTable(buf,
> >> true);
> >> >>> CalciteAssert.that()
> >> >>> .with(newSchema("s", "beatles", table))
> >> >>> .query("select \"i\" as theKey from \"s\".\"beatles\"")
> >> >>> .explainContains("EnumerableInterpreter\n"
> >> >>> + "  BindableTableScan(table=[[s, beatles]],
> >> >>> projects=[[0]])\n")
> >> >>> .returnsUnordered("THEKEY=4",
> >> >>> "THEKEY=4",
> >> >>> "THEKEY=6",
> >> >>> "THEKEY=5");  }
> >> >>> It passes for me.
> >> >>> You'll need the updated version of this test class, because it was
> >> >>> recently refactored.
> >> >>> It's usually easier for other people to test the problem if you
> create
> >> >>> runnable test cases to show the problem.   Em sexta-feira, 17 de
> >> novembro
> >> >>> de 2017 14:29:09 BRST, Enrico Olivelli 
> escreveu:
> >> >>>
> >> >>>  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 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
> >> >>> > just does not show in the plan.
> >> >>> > However, I seems that repeating a column with different aliases
> >> >>> generates
> >> >>> > an error:
> >> >>> > SELECT k1 theKey, k1 theKey2 FROM tblspace1.tsql where k1
> ='mykey2'
> >> >>> >
> >> >>> > Regards,

Re: BindableTableScan is losing aliased named

[Julian Hyde]

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, y". The
RelNode needs to have 2 columns but the ResultSet thinks it only has
one.

Julian


On Fri, Nov 17, 2017 at 10:46 AM, Enrico Olivelli  wrote:
> 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 world, field names are a hint to make debugging
>> easier but are not ultimately reliable. The reliable way to reference
>> fields is by position.
>>
>
>
> I understand your point Julian. In my case I want the final resultset to
> have knowledge of the alias requested by the user.
>
> Select a as b from table
>
> ResultSet rs = ...
> String col = rs.getString("b");
> If I am losing the alias I can't support this case.
> The test case from Luis is working so there is some trick I am missing
>
> Enrico
>
>
>> Julian
>>
>>
>> On Fri, Nov 17, 2017 at 9:33 AM, Enrico Olivelli 
>> wrote:
>> > I run the debugger on your test case.
>> > IMHO The BindableTableScan RelNode does not keep the original aliases of
>> > the query.
>> > The test cases runs CalciteConnection, maybe there is some magic during
>> the
>> > execution of the query.
>> > Can you provide me some insight ?
>> > Maybe it is better that I provide a reproducer.
>> > I am not using CalciteConnection but only the planner
>> >
>> > Thanks
>> > Enrico
>> >
>> > 2017-11-17 18:08 GMT+01:00 Enrico Olivelli :
>> >
>> >> 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 Kauer <
>> >> lfka...@yahoo.com.br.invalid>:
>> >>
>> >>> 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 BeatlesProjectableFilterableTable(buf,
>> true);
>> >>> CalciteAssert.that()
>> >>> .with(newSchema("s", "beatles", table))
>> >>> .query("select \"i\" as theKey from \"s\".\"beatles\"")
>> >>> .explainContains("EnumerableInterpreter\n"
>> >>> + "  BindableTableScan(table=[[s, beatles]],
>> >>> projects=[[0]])\n")
>> >>> .returnsUnordered("THEKEY=4",
>> >>> "THEKEY=4",
>> >>> "THEKEY=6",
>> >>> "THEKEY=5");  }
>> >>> It passes for me.
>> >>> You'll need the updated version of this test class, because it was
>> >>> recently refactored.
>> >>> It's usually easier for other people to test the problem if you create
>> >>> runnable test cases to show the problem.   Em sexta-feira, 17 de
>> novembro
>> >>> de 2017 14:29:09 BRST, Enrico Olivelli  escreveu:
>> >>>
>> >>>  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 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
>> >>> > just does not show in the plan.
>> >>> > However, I seems that repeating a column with different aliases
>> >>> generates
>> >>> > an error:
>> >>> > SELECT k1 theKey, k1 theKey2 FROM tblspace1.tsql where k1 ='mykey2'
>> >>> >
>> >>> > Regards,
>> >>> > Luis Fernando
>> >>> >
>> >>> >Em sexta-feira, 17 de novembro de 2017 12:27:49 BRST, Enrico
>> >>> Olivelli <
>> >>> > eolive...@gmail.com> escreveu:
>> >>> >
>> >>> >  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])
>> >>> >  LogicalFilter(condition=[=($0, 'mykey2')])
>> >>> >EnumerableTableScan(table=[[tblspace1, tsql]])
>> >>> >
>> >>> > -- Best Plan
>> >>> > 

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

[Sergio Sainz (JIRA)]

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: Bug
  Components: avatica
Affects Versions: 1.11.0
Reporter: Sergio Sainz
Priority: Minor


When running the following code we see the null pointer exception below:

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.util.Properties;

/**
 * Created by ssainz on 11/17/17.
 */

public class druid_jdbc {
  public static void main (String[] args) throws ClassNotFoundException, 
SQLException
  {

//Class.forName("org.apache.calcite.jdbc.Driver");
String url = 
"jdbc:avatica:remote:url=http://host:8082/druid/v2/sql/avatica/;;
Properties connectionProperties = new Properties();
try (Connection connection = DriverManager.getConnection(url, 
connectionProperties)) {
  connection.getMetaData().getTypeInfo();
  try (ResultSet resultSet = 
connection.createStatement().executeQuery("SELECT COUNT(*) AS cnt FROM 
CUSTOMER")) {
int i = 0;
while (resultSet.next()) {
  int cnt = resultSet.getInt("cnt");
  System.out.println("It " + i + " count: " + cnt);
  i++;
}
  }
}
  }
}



Exception in thread "main" AvaticaClientRuntimeException: Remote driver error: 
NullPointerException: (null exception message). Error -1 (0) UNKNOWN

java.lang.NullPointerException
at 
org.apache.calcite.avatica.MetaImpl.createResultSet(MetaImpl.java:288)
at 
org.apache.calcite.avatica.MetaImpl.createEmptyResultSet(MetaImpl.java:219)
at org.apache.calcite.avatica.MetaImpl.getTypeInfo(MetaImpl.java:1380)
at 
org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:188)
at 
org.apache.calcite.avatica.remote.Service$TypeInfoRequest.accept(Service.java:701)
at 
org.apache.calcite.avatica.remote.Service$TypeInfoRequest.accept(Service.java:686)
at 
org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:95)
at 
org.apache.calcite.avatica.remote.JsonHandler.apply(JsonHandler.java:52)
at 
org.apache.calcite.avatica.server.AvaticaJsonHandler.handle(AvaticaJsonHandler.java:129)
at 
io.druid.sql.avatica.DruidAvaticaHandler.handle(DruidAvaticaHandler.java:63)
at 
org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
at org.eclipse.jetty.server.Server.handle(Server.java:534)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)
at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108)
at 
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)
at java.lang.Thread.run(Thread.java:748)


at 
org.apache.calcite.avatica.remote.Service$ErrorResponse.toException(Service.java:2476)
at 
org.apache.calcite.avatica.remote.JsonService.decode(JsonService.java:55)
at 
org.apache.calcite.avatica.remote.JsonService.apply(JsonService.java:108)
at 
org.apache.calcite.avatica.remote.RemoteMeta$10.call(RemoteMeta.java:213)
at 
org.apache.calcite.avatica.remote.RemoteMeta$10.call(RemoteMeta.java:210)
at 
org.apache.calcite.avatica.AvaticaConnection.invokeWithRetries(AvaticaConnection.java:756)
at 
org.apache.calcite.avatica.remote.RemoteMeta.getTypeInfo(RemoteMeta.java:209)
at 
org.apache.calcite.avatica.AvaticaDatabaseMetaData$22.call(AvaticaDatabaseMetaData.java:1010)
at 
org.apache.calcite.avatica.AvaticaDatabaseMetaData$22.call(AvaticaDatabaseMetaData.java:1007)
at 
org.apache.calcite.avatica.AvaticaConnection.invokeWithRetries(AvaticaConnection.java:756)
at 
org.apache.calcite.avatica.AvaticaDatabaseMetaData.getTypeInfo(AvaticaDatabaseMetaData.java:1006)
at druid_jdbc.main(druid_jdbc.java:19)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

Re: BindableTableScan is losing aliased named

[Enrico Olivelli]

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 world, field names are a hint to make debugging
> easier but are not ultimately reliable. The reliable way to reference
> fields is by position.
>


I understand your point Julian. In my case I want the final resultset to
have knowledge of the alias requested by the user.

Select a as b from table

ResultSet rs = ...
String col = rs.getString("b");
If I am losing the alias I can't support this case.
The test case from Luis is working so there is some trick I am missing

Enrico


> Julian
>
>
> On Fri, Nov 17, 2017 at 9:33 AM, Enrico Olivelli 
> wrote:
> > I run the debugger on your test case.
> > IMHO The BindableTableScan RelNode does not keep the original aliases of
> > the query.
> > The test cases runs CalciteConnection, maybe there is some magic during
> the
> > execution of the query.
> > Can you provide me some insight ?
> > Maybe it is better that I provide a reproducer.
> > I am not using CalciteConnection but only the planner
> >
> > Thanks
> > Enrico
> >
> > 2017-11-17 18:08 GMT+01:00 Enrico Olivelli :
> >
> >> 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 Kauer <
> >> lfka...@yahoo.com.br.invalid>:
> >>
> >>> 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 BeatlesProjectableFilterableTable(buf,
> true);
> >>> CalciteAssert.that()
> >>> .with(newSchema("s", "beatles", table))
> >>> .query("select \"i\" as theKey from \"s\".\"beatles\"")
> >>> .explainContains("EnumerableInterpreter\n"
> >>> + "  BindableTableScan(table=[[s, beatles]],
> >>> projects=[[0]])\n")
> >>> .returnsUnordered("THEKEY=4",
> >>> "THEKEY=4",
> >>> "THEKEY=6",
> >>> "THEKEY=5");  }
> >>> It passes for me.
> >>> You'll need the updated version of this test class, because it was
> >>> recently refactored.
> >>> It's usually easier for other people to test the problem if you create
> >>> runnable test cases to show the problem.   Em sexta-feira, 17 de
> novembro
> >>> de 2017 14:29:09 BRST, Enrico Olivelli  escreveu:
> >>>
> >>>  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 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
> >>> > just does not show in the plan.
> >>> > However, I seems that repeating a column with different aliases
> >>> generates
> >>> > an error:
> >>> > SELECT k1 theKey, k1 theKey2 FROM tblspace1.tsql where k1 ='mykey2'
> >>> >
> >>> > Regards,
> >>> > Luis Fernando
> >>> >
> >>> >Em sexta-feira, 17 de novembro de 2017 12:27:49 BRST, Enrico
> >>> Olivelli <
> >>> > eolive...@gmail.com> escreveu:
> >>> >
> >>> >  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])
> >>> >  LogicalFilter(condition=[=($0, 'mykey2')])
> >>> >EnumerableTableScan(table=[[tblspace1, tsql]])
> >>> >
> >>> > -- Best Plan
> >>> > EnumerableInterpreter
> >>> >  BindableTableScan(table=[[tblspace1, tsql]], filters=[[=($0,
> >>> > 'mykey2')]],
> >>> > projects=[[0]])
> >>> >
> >>> > Is this correct ?
> >>> > IMHO It would better to keep somethin like an EnumerableProjection
> which
> >>> > renames the fields
> >>> >
> >>> > Am I missing something ?
> >>> > Thanks
> >>> > Enrico
> >>> >
> >>> >
> >>>
> >>>
> >>
> >>
>
-- 


-- Enrico Olivelli

Re: Columns with name "value"

[Enrico Olivelli]

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
> that we would merge into Calcite.
>

Oh, I don't like forks. I think I will try to live without this

Cheers
Enrico

>
> --
> Michael Mior
> mm...@apache.org
>
> 2017-11-17 3:32 GMT-05:00 Enrico Olivelli :
>
> > 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 or rename the column.
> > >
> > > Julian
> > >
> > >
> > > > On Nov 16, 2017, at 6:01 AM, Enrico Olivelli 
> > > wrote:
> > > >
> > > > Is it possible to make Calcite SqlParser accept queries on column
> with
> > > name
> > > > "value" without quoting ?
> > > > like
> > > > insert into mytable(name,value values(1,2)
> > > >
> > > > I am using Mysql 5.5 conformance and lex
> > > >
> > > > below the error
> > > > Cheers
> > > > Enrico
> > > >
> > > > org.apache.calcite.sql.parser.SqlParseException: Encountered ",
> > value" at
> > > > line 1, column 37.
> > > > Was expecting one of:
> > > >")" ...
> > > >"CHARACTER" ...
> > > >"CHAR" ...
> > > >"VARCHAR" ...
> > > >"DATE" ...
> > > >"TIME" ...
> > > >"TIMESTAMP" ...
> > > >"DECIMAL" ...
> > > >"DEC" ...
> > > >"NUMERIC" ...
> > > >"BOOLEAN" ...
> > > >"INTEGER" ...
> > > >"INT" ...
> > > >"BINARY" ...
> > > >"VARBINARY" ...
> > > >"TINYINT" ...
> > > >"SMALLINT" ...
> > > >"BIGINT" ...
> > > >"REAL" ...
> > > >"DOUBLE" ...
> > > >"FLOAT" ...
> > > >"ANY" ...
> > > >"MULTISET" ...
> > > > ...
> > > > ...
> > > > ...
> > > > ...
> > > > ...
> > > >"." ...
> > > >","  ...
> > > >","  ...
> > > >","  ...
> > > >","  ...
> > > >","  ...
> > > >
> > > > herddb.model.StatementExecutionException
> > > > org.apache.calcite.sql.parser.SqlParseException: Encountered ",
> > value" at
> > > > line 1, column 37.
> > > > Was expecting one of:
> > > >")" ...
> > > >"CHARACTER" ...
> > > >"CHAR" ...
> > > >"VARCHAR" ...
> > > >"DATE" ...
> > > >"TIME" ...
> > > >"TIMESTAMP" ...
> > > >"DECIMAL" ...
> > > >"DEC" ...
> > > >"NUMERIC" ...
> > > >"BOOLEAN" ...
> > > >"INTEGER" ...
> > > >"INT" ...
> > > >"BINARY" ...
> > > >"VARBINARY" ...
> > > >"TINYINT" ...
> > > >"SMALLINT" ...
> > > >"BIGINT" ...
> > > >"REAL" ...
> > > >"DOUBLE" ...
> > > >"FLOAT" ...
> > > >"ANY" ...
> > > >"MULTISET" ...
> > > > ...
> > > > ...
> > > > ...
> > > > ...
> > > > ...
> > > >"." ...
> > > >","  ...
> > > >","  ...
> > > >","  ...
> > > >","  ...
> > > >","  ...
> > > >
> > > >at herddb.sql.CalcitePlanner.translate(CalcitePlanner.java:249)
> > > >at herddb.core.TestUtils.executeUpdate(TestUtils.java:43)
> > > >at
> > > >
> > > herddb.core.SecondaryIndexAccessSuite.secondaryIndexPrefixScanInSubq
> > uery(SecondaryIndexAccessSuite.java:396)
> > > >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > >at
> > > >
> > > sun.reflect.NativeMethodAccessorImpl.invoke(
> > NativeMethodAccessorImpl.java:62)
> > > >at
> > > >
> > > sun.reflect.DelegatingMethodAccessorImpl.invoke(
> > DelegatingMethodAccessorImpl.java:43)
> > > >at java.lang.reflect.Method.invoke(Method.java:498)
> > > >at
> > > >
> > > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(
> > FrameworkMethod.java:50)
> > > >at
> > > >
> > > org.junit.internal.runners.model.ReflectiveCallable.run(
> > ReflectiveCallable.java:12)
> > > >at
> > > >
> > > org.junit.runners.model.FrameworkMethod.invokeExplosively(
> > FrameworkMethod.java:47)
> > > >at
> > > >
> > > org.junit.internal.runners.statements.InvokeMethod.
> > evaluate(InvokeMethod.java:17)
> > > >at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> > > >at
> > > >
> > > org.junit.runners.BlockJUnit4ClassRunner.runChild(
> > BlockJUnit4ClassRunner.java:78)
> > > >at
> > > >
> > > org.junit.runners.BlockJUnit4ClassRunner.runChild(
> > BlockJUnit4ClassRunner.java:57)
> > > >at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> > > >at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> > > >at org.junit.runners.ParentRunner.runChildren(
> > ParentRunner.java:288)
> > > >at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> > > >at
> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> > > 

Re: Support for "limit ?"

[Julian Hyde]

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, SqlValidatorTest, and JdbcTest with both negative
and positive tests. Then I'd make code changes until they pass. It
sounds flippant, but I literally don't know which code I would need to
change, but the tests (and a debugger) would help me figure it out.

Julian


On Fri, Nov 17, 2017 at 5:43 AM, Enrico Olivelli  wrote:
> 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 create a patch ?
>
> This fix will be very important because YCSB benchmarks use this syntax
>
> Thanks
> I hope to be ready to use Calcite soon in my project
>
> Enrico

Re: BindableTableScan is losing aliased named

[Julian Hyde]

> 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 reliable. The reliable way to reference
fields is by position.

Julian


On Fri, Nov 17, 2017 at 9:33 AM, Enrico Olivelli  wrote:
> I run the debugger on your test case.
> IMHO The BindableTableScan RelNode does not keep the original aliases of
> the query.
> The test cases runs CalciteConnection, maybe there is some magic during the
> execution of the query.
> Can you provide me some insight ?
> Maybe it is better that I provide a reproducer.
> I am not using CalciteConnection but only the planner
>
> Thanks
> Enrico
>
> 2017-11-17 18:08 GMT+01:00 Enrico Olivelli :
>
>> 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 Kauer <
>> lfka...@yahoo.com.br.invalid>:
>>
>>> 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 BeatlesProjectableFilterableTable(buf, true);
>>> CalciteAssert.that()
>>> .with(newSchema("s", "beatles", table))
>>> .query("select \"i\" as theKey from \"s\".\"beatles\"")
>>> .explainContains("EnumerableInterpreter\n"
>>> + "  BindableTableScan(table=[[s, beatles]],
>>> projects=[[0]])\n")
>>> .returnsUnordered("THEKEY=4",
>>> "THEKEY=4",
>>> "THEKEY=6",
>>> "THEKEY=5");  }
>>> It passes for me.
>>> You'll need the updated version of this test class, because it was
>>> recently refactored.
>>> It's usually easier for other people to test the problem if you create
>>> runnable test cases to show the problem.   Em sexta-feira, 17 de novembro
>>> de 2017 14:29:09 BRST, Enrico Olivelli  escreveu:
>>>
>>>  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 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
>>> > just does not show in the plan.
>>> > However, I seems that repeating a column with different aliases
>>> generates
>>> > an error:
>>> > SELECT k1 theKey, k1 theKey2 FROM tblspace1.tsql where k1 ='mykey2'
>>> >
>>> > Regards,
>>> > Luis Fernando
>>> >
>>> >Em sexta-feira, 17 de novembro de 2017 12:27:49 BRST, Enrico
>>> Olivelli <
>>> > eolive...@gmail.com> escreveu:
>>> >
>>> >  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])
>>> >  LogicalFilter(condition=[=($0, 'mykey2')])
>>> >EnumerableTableScan(table=[[tblspace1, tsql]])
>>> >
>>> > -- Best Plan
>>> > EnumerableInterpreter
>>> >  BindableTableScan(table=[[tblspace1, tsql]], filters=[[=($0,
>>> > 'mykey2')]],
>>> > projects=[[0]])
>>> >
>>> > Is this correct ?
>>> > IMHO It would better to keep somethin like an EnumerableProjection which
>>> > renames the fields
>>> >
>>> > Am I missing something ?
>>> > Thanks
>>> > Enrico
>>> >
>>> >
>>>
>>>
>>
>>

Re: BindableTableScan is losing aliased named

[Enrico Olivelli]

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 Kauer :

> 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 BeatlesProjectableFilterableTable(buf, true);
> CalciteAssert.that()
> .with(newSchema("s", "beatles", table))
> .query("select \"i\" as theKey from \"s\".\"beatles\"")
> .explainContains("EnumerableInterpreter\n"
> + "  BindableTableScan(table=[[s, beatles]],
> projects=[[0]])\n")
> .returnsUnordered("THEKEY=4",
> "THEKEY=4",
> "THEKEY=6",
> "THEKEY=5");  }
> It passes for me.
> You'll need the updated version of this test class, because it was
> recently refactored.
> It's usually easier for other people to test the problem if you create
> runnable test cases to show the problem.   Em sexta-feira, 17 de novembro
> de 2017 14:29:09 BRST, Enrico Olivelli  escreveu:
>
>  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 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
> > just does not show in the plan.
> > However, I seems that repeating a column with different aliases generates
> > an error:
> > SELECT k1 theKey, k1 theKey2 FROM tblspace1.tsql where k1 ='mykey2'
> >
> > Regards,
> > Luis Fernando
> >
> >Em sexta-feira, 17 de novembro de 2017 12:27:49 BRST, Enrico Olivelli
> <
> > eolive...@gmail.com> escreveu:
> >
> >  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])
> >  LogicalFilter(condition=[=($0, 'mykey2')])
> >EnumerableTableScan(table=[[tblspace1, tsql]])
> >
> > -- Best Plan
> > EnumerableInterpreter
> >  BindableTableScan(table=[[tblspace1, tsql]], filters=[[=($0,
> > 'mykey2')]],
> > projects=[[0]])
> >
> > Is this correct ?
> > IMHO It would better to keep somethin like an EnumerableProjection which
> > renames the fields
> >
> > Am I missing something ?
> > Thanks
> > Enrico
> >
> >
>
>

Re: BindableTableScan is losing aliased named

[Luis Fernando Kauer]

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 BeatlesProjectableFilterableTable(buf, true);
    CalciteAssert.that()
        .with(newSchema("s", "beatles", table))
        .query("select \"i\" as theKey from \"s\".\"beatles\"")
        .explainContains("EnumerableInterpreter\n"
            + "  BindableTableScan(table=[[s, beatles]], projects=[[0]])\n")
        .returnsUnordered("THEKEY=4",
            "THEKEY=4",
            "THEKEY=6",
            "THEKEY=5");  }
It passes for me.
You'll need the updated version of this test class, because it was recently 
refactored.
It's usually easier for other people to test the problem if you create runnable 
test cases to show the problem.   Em sexta-feira, 17 de novembro de 2017 
14:29:09 BRST, Enrico Olivelli  escreveu:  
 
 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 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
> just does not show in the plan.
> However, I seems that repeating a column with different aliases generates
> an error:
> SELECT k1 theKey, k1 theKey2 FROM tblspace1.tsql where k1 ='mykey2'
>
> Regards,
> Luis Fernando
>
>    Em sexta-feira, 17 de novembro de 2017 12:27:49 BRST, Enrico Olivelli <
> eolive...@gmail.com> escreveu:
>
>  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])
>  LogicalFilter(condition=[=($0, 'mykey2')])
>    EnumerableTableScan(table=[[tblspace1, tsql]])
>
> -- Best Plan
> EnumerableInterpreter
>  BindableTableScan(table=[[tblspace1, tsql]], filters=[[=($0,
> 'mykey2')]],
> projects=[[0]])
>
> Is this correct ?
> IMHO It would better to keep somethin like an EnumerableProjection which
> renames the fields
>
> Am I missing something ?
> Thanks
> Enrico
>
>
  

Re: BindableTableScan is losing aliased named

[Enrico Olivelli]

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 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
> just does not show in the plan.
> However, I seems that repeating a column with different aliases generates
> an error:
> SELECT k1 theKey, k1 theKey2 FROM tblspace1.tsql where k1 ='mykey2'
>
> Regards,
> Luis Fernando
>
> Em sexta-feira, 17 de novembro de 2017 12:27:49 BRST, Enrico Olivelli <
> eolive...@gmail.com> escreveu:
>
>  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])
>   LogicalFilter(condition=[=($0, 'mykey2')])
> EnumerableTableScan(table=[[tblspace1, tsql]])
>
> -- Best Plan
> EnumerableInterpreter
>   BindableTableScan(table=[[tblspace1, tsql]], filters=[[=($0,
> 'mykey2')]],
> projects=[[0]])
>
> Is this correct ?
> IMHO It would better to keep somethin like an EnumerableProjection which
> renames the fields
>
> Am I missing something ?
> Thanks
> Enrico
>
>

Re: BindableTableScan is losing aliased named

[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 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 just 
does not show in the plan.
However, I seems that repeating a column with different aliases generates an 
error:
SELECT k1 theKey, k1 theKey2 FROM tblspace1.tsql where k1 ='mykey2'

Regards,
Luis Fernando

Em sexta-feira, 17 de novembro de 2017 12:27:49 BRST, Enrico Olivelli 
 escreveu:  
 
 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])
  LogicalFilter(condition=[=($0, 'mykey2')])
    EnumerableTableScan(table=[[tblspace1, tsql]])

-- Best Plan
EnumerableInterpreter
  BindableTableScan(table=[[tblspace1, tsql]], filters=[[=($0, 'mykey2')]],
projects=[[0]])

Is this correct ?
IMHO It would better to keep somethin like an EnumerableProjection which
renames the fields

Am I missing something ?
Thanks
Enrico
  

BindableTableScan is losing aliased named

[Enrico Olivelli]

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])
  LogicalFilter(condition=[=($0, 'mykey2')])
EnumerableTableScan(table=[[tblspace1, tsql]])

-- Best Plan
EnumerableInterpreter
  BindableTableScan(table=[[tblspace1, tsql]], filters=[[=($0, 'mykey2')]],
projects=[[0]])

Is this correct ?
IMHO It would better to keep somethin like an EnumerableProjection which
renames the fields

Am I missing something ?
Thanks
Enrico

Support for "limit ?"

[Enrico Olivelli]

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 create a patch ?

This fix will be very important because YCSB benchmarks use this syntax

Thanks
I hope to be ready to use Calcite soon in my project

Enrico

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

[Christian Tzolov (JIRA)]

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
Reporter: Christian Tzolov
Assignee: Julian Hyde


I've been working on a Calcite adapter for [Apache 
Geode|http://geode.apache.org]. 
Current implementation uses the plain Geode API and 
[OQL|http://geode.apache.org/docs/guide/13/developing/querying_basics/chapter_overview.html](Object
 Query Interface) to push down relational expressions such as projections, 
filtering, sorting, and grouping . 

Provided functionality can hopefully address certain Geode use cases and will 
provide a stepping stone for future improvements. 

Here are some remaining tasks as i see it:
* New tests for test suite (and update calcite-test-dataset to support Geode)
* Add Integration tests that use calcite-test-dataset
* Documentation



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Parser error on trivial JDBC update

[Enrico Olivelli]

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 :

> OK
> I would like to pick up this issue and provide a fix.
>
> This is the test, working
> @Test public void testUpdateBind() {
> final String sql = "update emp"
> + " set sal = sal + ? where slacker = false";
> sql(sql).ok();
>   }
>
> This is a new, simpler test, which is not working, same error as expected
>   @Test public void testUpdateBind2() {
> final String sql = "update emp"
> + " set sal = ? where slacker = false";
> sql(sql).ok();
>   }
>
> Below this test there is a test marked as @Ignore due to CALCITE-1708,
> which is the same problem, but the test case was more complex.
>
> Can you give me some hint ?
> I am still a newbie in Calcite.
> How is it supposed to be bound the type for a dynamic parameter?
> In this case I think we could derive the type from the column which is
> going to be updated/filtered.
> Another approach would be to drop the assertion in this special case. I
> don't think it is bad to have a unknown type in this case, but maybe I am
> missing something.
>
>
> 2017-11-15 14:06 GMT+01:00 Enrico Olivelli :
>
>> here it is
>> https://issues.apache.org/jira/browse/CALCITE-2054
>>
>> 2017-11-15 14:02 GMT+01:00 Enrico Olivelli :
>>
>>> I will do,
>>> It crashes even if I switch to ProjectableFilterableTable I fall into
>>> this,
>>>
>>> For updates without parameters and using ProjectableFilterableTable I
>>> fall into this
>>> https://issues.apache.org/jira/browse/CALCITE-2039
>>> I have attached a reproducer.
>>>
>>> The same is for this email, I will create a JIRA now
>>>
>>> Can you please take into account of addressing the two for 1.15 ? They
>>> are realy blocker.
>>> At least CALCITE-2039
>>> In fact I went away from ProjectableFilterableTable because of
>>> CALCITE-2039
>>>
>>> I will do my best to support triage and testing,
>>> Thanks
>>> I hope to be able to leverage Calcite power soon
>>>
>>> Enrico
>>>
>>> 2017-11-14 23:55 GMT+01:00 Julian Hyde :
>>>
 I see we have SqlValidatorTest.testUpdateBind(), which seems very
 similar to your query, and it succeeds validation. But I don’t recall us
 testing dynamic parameters in the SET clause end-to-end, and your query is
 failing in sql-to-rel translation, just after validation. Can you log a
 JIRA case please?

 Julian


 > On Nov 14, 2017, at 12:45 PM, Enrico Olivelli 
 wrote:
 >
 > Hi,
 > with a simple UPDATE like:
 > UPDATE mytable set a=? where b=?
 >
 > I get the error below.
 > The "Table" is a ModifiableTable + ScannableTable, with "a" of type
 INTEGER
 > and "b" of type VARCHAR
 >
 > Any hint ?
 > Thank you
 > Enrico
 >
 >
 > org.apache.calcite.runtime.CalciteContextException: At line 1,
 column 30:
 > Illegal use of dynamic parameter
 >at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
 Method)
 >at
 > sun.reflect.NativeConstructorAccessorImpl.newInstance(Native
 ConstructorAccessorImpl.java:62)
 >at
 > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(De
 legatingConstructorAccessorImpl.java:45)
 >at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
 >at
 > org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Reso
 urces.java:463)
 >at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.j
 ava:803)
 >at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.j
 ava:788)
 >at
 > org.apache.calcite.sql.validate.SqlValidatorImpl.newValidati
 onError(SqlValidatorImpl.java:4651)
 >at
 > org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknow
 nTypes(SqlValidatorImpl.java:1694)
 >at
 > org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknow
 nTypes(SqlValidatorImpl.java:1769)
 >at
 > org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelec
 tItem(SqlValidatorImpl.java:457)
 >at
 > org.apache.calcite.sql.validate.SqlValidatorImpl.expandStar(
 SqlValidatorImpl.java:347)
 >at
 > org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectLi
 st(SqlToRelConverter.java:3709)
 >at
 > org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectIm
 pl(SqlToRelConverter.java:663)
 >at
 > org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(S
 qlToRelConverter.java:620)
 >at
 > org.apache.calcite.sql2rel.SqlToRelConverter.convertUpdate(S
 qlToRelConverter.java:3398)
 >at
 > 

Re: Columns with name "value"

[Enrico Olivelli]

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 or rename the column.
>
> Julian
>
>
> > On Nov 16, 2017, at 6:01 AM, Enrico Olivelli 
> wrote:
> >
> > Is it possible to make Calcite SqlParser accept queries on column with
> name
> > "value" without quoting ?
> > like
> > insert into mytable(name,value values(1,2)
> >
> > I am using Mysql 5.5 conformance and lex
> >
> > below the error
> > Cheers
> > Enrico
> >
> > org.apache.calcite.sql.parser.SqlParseException: Encountered ", value" at
> > line 1, column 37.
> > Was expecting one of:
> >")" ...
> >"CHARACTER" ...
> >"CHAR" ...
> >"VARCHAR" ...
> >"DATE" ...
> >"TIME" ...
> >"TIMESTAMP" ...
> >"DECIMAL" ...
> >"DEC" ...
> >"NUMERIC" ...
> >"BOOLEAN" ...
> >"INTEGER" ...
> >"INT" ...
> >"BINARY" ...
> >"VARBINARY" ...
> >"TINYINT" ...
> >"SMALLINT" ...
> >"BIGINT" ...
> >"REAL" ...
> >"DOUBLE" ...
> >"FLOAT" ...
> >"ANY" ...
> >"MULTISET" ...
> > ...
> > ...
> > ...
> > ...
> > ...
> >"." ...
> >","  ...
> >","  ...
> >","  ...
> >","  ...
> >","  ...
> >
> > herddb.model.StatementExecutionException
> > org.apache.calcite.sql.parser.SqlParseException: Encountered ", value" at
> > line 1, column 37.
> > Was expecting one of:
> >")" ...
> >"CHARACTER" ...
> >"CHAR" ...
> >"VARCHAR" ...
> >"DATE" ...
> >"TIME" ...
> >"TIMESTAMP" ...
> >"DECIMAL" ...
> >"DEC" ...
> >"NUMERIC" ...
> >"BOOLEAN" ...
> >"INTEGER" ...
> >"INT" ...
> >"BINARY" ...
> >"VARBINARY" ...
> >"TINYINT" ...
> >"SMALLINT" ...
> >"BIGINT" ...
> >"REAL" ...
> >"DOUBLE" ...
> >"FLOAT" ...
> >"ANY" ...
> >"MULTISET" ...
> > ...
> > ...
> > ...
> > ...
> > ...
> >"." ...
> >","  ...
> >","  ...
> >","  ...
> >","  ...
> >","  ...
> >
> >at herddb.sql.CalcitePlanner.translate(CalcitePlanner.java:249)
> >at herddb.core.TestUtils.executeUpdate(TestUtils.java:43)
> >at
> >
> herddb.core.SecondaryIndexAccessSuite.secondaryIndexPrefixScanInSubquery(SecondaryIndexAccessSuite.java:396)
> >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >at
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> >at
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >at java.lang.reflect.Method.invoke(Method.java:498)
> >at
> >
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> >at
> >
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> >at
> >
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> >at
> >
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> >at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> >at
> >
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> >at
> >
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> >at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> >at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> >at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> >at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> >at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> >at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> >at
> >
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:369)
> >at
> >
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:275)
> >at
> >
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:239)
> >at
> >
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:160)
> >at
> >
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:373)
> >at
> >
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:334)
> >at
> >
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:119)
> >at
> > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:407)
> > Caused by: org.apache.calcite.sql.parser.SqlParseException: Encountered
> ",
> > value" at line 1, column 37.
> > Was expecting one of:
> >")" ...
> >"CHARACTER" ...
> >"CHAR" ...
> >"VARCHAR" ...
> >"DATE" ...
> >"TIME" ...
> >"TIMESTAMP" ...
> >