Thanks - I’ve added some comments to CALCITE-1527. Source expressions with sub-query are hard. Maybe you can represent them using RexSubQuery; and maybe RelDecorrelator can help; I’m not sure. In any case, I think you should defer them to another case.
In this case, it seems that you have implemented INSERT … VALUES but not INSERT … SELECT. Can you clarify whether you intend to do the latter? Julian > On Dec 5, 2016, at 2:21 AM, Christian Tzolov <[email protected]> wrote: > > Here it goes :) > - JIRA: https://issues.apache.org/jira/browse/CALCITE-1527 > - PR: https://github.com/apache/calcite/pull/334 > > Seems bit more involving than expected. In addition to the Sql > implementation, it requires changes on the SQL parsing side as well as the > handling for the non-ResultSet responses. There are still some open > questions like the handling of source expressions for UPDATE with > sub-query. > > > > > On 30 November 2016 at 23:15, Julian Hyde <[email protected]> wrote: > >> “Unfortunate” is one word for it. If Calcite were complete it would be >> considerably more expensive. :) >> >> You figured out how to implement OVER, so I’d look in a similar place for >> DML. >> >> Julian >> >>> On Nov 30, 2016, at 1:42 PM, Christian Tzolov <[email protected]> >> wrote: >>> >>> Thanks Julian, this is unfortunate as it undermines the idea of having >> jdbc >>> wrapper in front of HAWQ. >>> >>> I will log Jira tickets. How difficult do you think would be to provide >> DML >>> support for the JDBC adapter? If i am to take a look at it where should >>> look first? >>> >>> Cheers, >>> Christian >>> >>> On 30 November 2016 at 19:23, Julian Hyde <[email protected]> wrote: >>> >>>> It’s a missing feature. The JDBC adapter does not currently do DML. Can >>>> you please log a JIRA case to track. >>>> >>>> Julian >>>> >>>> >>>>> On Nov 30, 2016, at 7:56 AM, Christian Tzolov <[email protected]> >>>> wrote: >>>>> >>>>> A test to reproduce the problem: >>>>> >>>>> @Test public void testJdbcAdapterInsert() { >>>>> >>>>> CalciteAssert.model(JdbcTest.FOODMART_MODEL) >>>>> .enable(CalciteAssert.DB == POSTGRESQL) >>>>> .query("INSERT INTO \"foodmart\".\"expense_fact\"(\n" + >>>>> " \"store_id\", \"account_id\", \"exp_date\", >>>>> \"time_id\"," + >>>>> " \"category_id\", \"currency_id\", >>>> \"amount\")\n" + >>>>> " VALUES (666, 666, TIMESTAMP '1997-01-01 00:00:00', 666, >>>> '666', >>>>> 666, 666)") >>>>> .runs(); >>>>> } >>>>> >>>>> Run with -Dcalcite.test.db=postgresql >>>>> >>>>> >>>>> On 30 November 2016 at 15:37, Christian Tzolov <[email protected]> >>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> The insert statement via the JdbcAdapter fails with >>>>>> "rel#78:Subset#1.ENUMERABLE.[]] could not be implemented;" >>>>>> >>>>>> I'm testing SQL inserts using the foodmart dataset and postgresql >>>>>> configured as a backend. >>>>>> >>>>>> Following insert works find on postgresql but fails when run through >> the >>>>>> jdbc adapter: >>>>>> >>>>>> "INSERT INTO "foodmart"."expense_fact"("store_id", "account_id", >>>>>> "exp_date", "time_id", "category_id", "currency_id", "amount") VALUES >>>> (666, >>>>>> 666, TIMESTAMP '1997-01-01 00:00:00', 666, '666', 666, 666); >>>>>> >>>>>> The jdbc-adapter error: >>>>>> >>>>>> Error: Error while executing SQL "INSERT INTO >>>> "foodmart"."expense_fact"("store_id", >>>>>> "account_id", "exp_date", "time_id", "category_id", "currency_id", >>>>>> "amount") VALUES (666, 666, TIMESTAMP '1997-01-01 00:00:00', 666, >> '666', >>>>>> 666, 666)": Node [rel#78:Subset#1.ENUMERABLE.[]] could not be >>>>>> implemented; planner state: >>>>>> >>>>>> It looks like error occurs before the JdbcTableModificationRule# >> covert >>>> is >>>>>> reached. >>>>>> >>>>>> Is this a limitation or bug? >>>>>> >>>>>> Thanks, >>>>>> Christian >>>>>> >>>>> >>>> >>>> >> >> > > > -- > Christian Tzolov <http://www.linkedin.com/in/tzolov> | Solution Architect, > EMEA Practice Team | Pivotal <http://pivotal.io/> > [email protected]|+31610285517
