calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <jul...@hydromatic.net>
Subject Re: Bound parameters in create table statements
Date Fri, 03 Apr 2015 21:20:19 GMT
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 <ndimiduk@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 <jamestaylor@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 <ndimiduk@gmail.com> wrote:
>>> Adding back dev@calcite
>>> 
>>> On Wed, Apr 1, 2015 at 11:48 AM, Nick Dimiduk <ndimiduk@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 <ndimiduk@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.reid@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 <ndimiduk@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
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>> 


Mime
View raw message