I have logged https://issues.apache.org/jira/browse/CALCITE-664 to track this on the Calcite/Avatica side. We do not plan to fix it for Calcite 1.2.
> On Apr 1, 2015, at 1:48 PM, Nick Dimiduk <ndimi...@gmail.com> wrote: > > No crucial for functionality, but a component of our test suite. My goal > with this patch was to prove confidence in the implementation by having all > IT tests be parameterized to run directly against Phoenix, and against > Phoenix through the query server. Since this is used by the tests, it > stymies this goal. > > On Wed, Apr 1, 2015 at 12:11 PM, James Taylor <jamestay...@apache.org> > wrote: > >> 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 >>>>>>> >>>>>> >>>>> >>>>> >>>> >>
