For the SELECT example you use, Phoenix would infer the type based on the column type of ID. We don't support parameterized precision/scale create statements as you've shown. It's really only for the pre-split information, and that's mainly because there's not a good way to pass arbitrary byte[] values through constants - it's much easier to bind them with stmt.setBytes(1, arbitraryByteArray);
I think it's a detail, though, that can be left for later IMHO. It's not crucial functionality. FWIW, Phoenix infers types whenever possible, but sometimes it's ambiguous. For example: SELECT ? + ? FROM T; In theory, param 1 could be bound to a TIMESTAMP and param 2 to an INTEGER. Or they could both be DECIMAL, etc. If Phoenix can't figure it out, we use null for the type in the metadata APIs. On Wed, Apr 1, 2015 at 11:49 AM, Nick Dimiduk <ndimi...@gmail.com> wrote: > Adding back dev@calcite > > On Wed, Apr 1, 2015 at 11:48 AM, Nick Dimiduk <ndimi...@gmail.com> wrote: > >> Poking around with HSQLDB, it seems parameter metadata is made available >> after statement preparation for select statements. (Presumably inferred >> from column type, as in "SELECT * FROM TEST_TABLE WHERE id = ?". It does >> not support parameterized create statements: >> >> user=> (.prepareStatement conn "CREATE TABLE TEST_TABLE_P(id INTEGER NOT >> NULL, pk varchar(?) NOT NULL)") >> >> HsqlException unexpected token: ? org.hsqldb.error.Error.parseError (:-1) >> >> I think that if Phoenix is going to support parameterized create table >> statements, it should infer parameter types and populate ParameterMetaData >> accordingly. >> >> On Tue, Mar 31, 2015 at 1:06 PM, Nick Dimiduk <ndimi...@gmail.com> wrote: >> >>> Hi Gabriel, >>> >>> Yes, we do this in the Phoenix test harness for parameterizing split >>> points. See o.a.p.q.BaseTest#createTestTable(String, String, byte[][], >>> Long, boolean). I ran into this while porting QueryIT to run vs. the query >>> server. >>> >>> -n >>> >>> On Tue, Mar 31, 2015 at 11:58 AM, Gabriel Reid <gabriel.r...@gmail.com> >>> wrote: >>> >>>> Could you explain how you're using prepared statements for DDL >>>> statements? >>>> Are you parameterizing parts of the DDL statements with question marks to >>>> be filled in by the PreparedStatement parameters? >>>> >>>> On Tue, Mar 31, 2015 at 3:48 AM Nick Dimiduk <ndimi...@gmail.com> 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 >>>> > >>>> >>> >>> >>
