I wasn't even aware that JDBC let you prepare a DDL statement (such as CREATE TABLE). And if you can't prepare, you can't bind parameters.
Oracle's JDBC driver doc [ http://docs.oracle.com/cd/E11882_01/java.112/e16548/apxref.htm#JJDBC28932 ] has an apologetic tone, so they seem to think that it should be possible, even if they can't: > Executing DDL Statements > > You must execute Data Definition Language (DDL) statements with Statement > objects. If you use PreparedStatements objects orCallableStatements objects, > then the DDL statement takes effect only on the first execution. This can > cause > unexpected behavior if the SQL statements are in a statement cache. I see no reason in principle why Avatica should not allow you to prepare DDL, query the parameter types, then bind and execute. Provided the underlying engine supports it, of course. Julian > On Mar 30, 2015, at 9:47 PM, Nick Dimiduk <[email protected]> wrote: > > Working on PHOENIX-971, I'm wondering what the expected behavior should be > for PreparedStatements created from CREATE TABLE sql with parameters. > Calcite's Avatica depends on the statement to identify the parameter types > at compile time, and return meaningful values for method invocations on > ParameterMetaData. It looks like Phoenix's CreateTableCompiler is > recognizing the number of parameters in my sql, but is not inferring type > information. > > My question is: should Avatica be more flexible in allowing "fuzzy" > signatures for PreparedStatements, or should Phoenix's > StatementPlan#compile methods be determining parameter types in all cases? > > Thanks, > Nick
