calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Taylor <jamestay...@apache.org>
Subject Re: Bound parameters in create table statements
Date Wed, 01 Apr 2015 19:11:53 GMT
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