I'm currently adding JDBC support to Beam SQL! Unfortunately Calcite has two distinct entry points, one for JDBC and one for everything else (see CALCITE-1525). Eventually that will change, but I'd like to avoid having two versions of Beam SQL until Calcite converges on a single path for parsing SQL. Here are the options I am looking at:
1. Make JDBC the source of truth for Calcite config and state. Generate a FrameworkConfig based on the JDBC connection and continue to use the non-JDBC interface to Calcite. This option comes with the risk that the two paths into Calcite will diverge (as there is a bunch of code copied from Calcite to generate the config), but is the easiest to implement and understand. 2. Make JDBC the only path into Calcite. Use prepareStatement and unwrap to extract a BeamRelNode out of the JDBC interface. This eliminates a significant amount of code in Beam, but the unwrap path is a little convoluted. Both options leave the user facing non-JDBC interface to Beam SQL unchanged, these changes are internal. Andrew
