-1 The release brings regression in terms of AbstractQueryableTable(Object[]) vs EnumerableTableScan interaction.
I am not sure what is the best way to solve it. I suspect EnumerableTableScan users are impacted. Historically, Calcite treated AbstractQueryableTable(Object[].class) in a tricky way: 1) If the row type has more than one column, then Calcite expects Enumerator<Object[]> 2) If the row type has just a single column, then Calcite expects "unboxed Object[]". In CALCITE-488 this behavior was broken so for Object[].class tables Calcite always expects Object[] boxed rows. >From one view this new behavior is "less surprising", however the change was not intended. For instance, smart-csv-example is broken since it tries to use adaptive enumerator type depending on the number of projected columns. In particular, the change impacts my mat-calcite-plugin and I have no idea how I missed that when I was testing previous RC. I would suggest revert to the old mode when Object[].class kind of tables skip Object[] array for single-column rows. Well, the PhysType vs elementType API should be improved, however I would not want that improvement to hold the train. Any thoughts? Vladimir
