You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@phoenix.apache.org by Jamie Murray <Ja...@D2L.com> on 2015/01/07 20:32:00 UTC
Data type integer representation documentation
Hello,
I am looking to find documentation on the integer representation used by Phoenix for its data types listed here: http://phoenix.apache.org/language/datatypes.html
Here is what I have found so far, this came from a combination of java.sql types for the non-unsigned types and some phoenix investigation for the unsigned types.
-6 --> TINYINT
5 --> SMALLINT
4 --> INTEGER
-5 --> BIGINT
6 --> FLOAT
8 --> DOUBLE
3 --> DECIMAL
16 --> BOOLEAN
91 --> DATE
92 --> TIME
93 --> TIMESTAMP
12 --> VARCHAR
1 --> CHAR
-2 --> BINARY
-3 --> VARBINARY
9 --> UNSIGNED_INT
10 --> UNSIGNED_LONG
11 --> UNSIGNED_TINYINT
13 --> UNSIGNED_SMALLINT
14 --> UNSIGNED_FLOAT
15 --> UNSIGNED_DOUBLE
18 --> UNSIGNED_TIME
19 --> UNSIGNED_DATE
19 --> UNSIGNED_TIMESTAMP
As you can see I am actually getting the same value for UNSIGNED_DATE and UNSIGNED_TIMESTAMP, is this intended? Or am I getting incorrect information.
Thanks,
Jamie
Re: Data type integer representation documentation
Posted by James Taylor <ja...@apache.org>.
Hi Jamie,
This looks like a bug - UNSIGNED_TIMESTAMP should have a unique sql
type. Would you mind filing a JIRA?
Thanks,
James
On Wed, Jan 7, 2015 at 2:55 PM, Nick Dimiduk <nd...@gmail.com> wrote:
> Your observation that UNSIGNED_DATE and UNSIGNED_TIMESTAMP share a common
> sql type is correct, at least on the 4.2 branch and on master.
>
> On Wed, Jan 7, 2015 at 11:32 AM, Jamie Murray <Ja...@d2l.com> wrote:
>>
>> Hello,
>>
>>
>>
>> I am looking to find documentation on the integer representation used by
>> Phoenix for its data types listed here:
>> http://phoenix.apache.org/language/datatypes.html
>>
>>
>>
>> Here is what I have found so far, this came from a combination of java.sql
>> types for the non-unsigned types and some phoenix investigation for the
>> unsigned types.
>>
>>
>>
>> -6 --> TINYINT
>>
>> 5 --> SMALLINT
>>
>> 4 --> INTEGER
>>
>> -5 --> BIGINT
>>
>> 6 --> FLOAT
>>
>> 8 --> DOUBLE
>>
>> 3 --> DECIMAL
>>
>> 16 --> BOOLEAN
>>
>> 91 --> DATE
>>
>> 92 --> TIME
>>
>> 93 --> TIMESTAMP
>>
>> 12 --> VARCHAR
>>
>> 1 --> CHAR
>>
>> -2 --> BINARY
>>
>> -3 --> VARBINARY
>>
>> 9 --> UNSIGNED_INT
>>
>> 10 --> UNSIGNED_LONG
>>
>> 11 --> UNSIGNED_TINYINT
>>
>> 13 --> UNSIGNED_SMALLINT
>>
>> 14 --> UNSIGNED_FLOAT
>>
>> 15 --> UNSIGNED_DOUBLE
>>
>> 18 --> UNSIGNED_TIME
>>
>> 19 --> UNSIGNED_DATE
>>
>> 19 --> UNSIGNED_TIMESTAMP
>>
>>
>>
>> As you can see I am actually getting the same value for UNSIGNED_DATE and
>> UNSIGNED_TIMESTAMP, is this intended? Or am I getting incorrect
>> information.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Jamie
>
>
Re: Data type integer representation documentation
Posted by Nick Dimiduk <nd...@gmail.com>.
Your observation that UNSIGNED_DATE and UNSIGNED_TIMESTAMP share a common
sql type is correct, at least on the 4.2 branch and on master.
On Wed, Jan 7, 2015 at 11:32 AM, Jamie Murray <Ja...@d2l.com> wrote:
> Hello,
>
>
>
> I am looking to find documentation on the integer representation used by
> Phoenix for its data types listed here:
> http://phoenix.apache.org/language/datatypes.html
>
>
>
> Here is what I have found so far, this came from a combination of java.sql
> types for the non-unsigned types and some phoenix investigation for the
> unsigned types.
>
>
>
> -6 --> TINYINT
>
> 5 --> SMALLINT
>
> 4 --> INTEGER
>
> -5 --> BIGINT
>
> 6 --> FLOAT
>
> 8 --> DOUBLE
>
> 3 --> DECIMAL
>
> 16 --> BOOLEAN
>
> 91 --> DATE
>
> 92 --> TIME
>
> 93 --> TIMESTAMP
>
> 12 --> VARCHAR
>
> 1 --> CHAR
>
> -2 --> BINARY
>
> -3 --> VARBINARY
>
> 9 --> UNSIGNED_INT
>
> 10 --> UNSIGNED_LONG
>
> 11 --> UNSIGNED_TINYINT
>
> 13 --> UNSIGNED_SMALLINT
>
> 14 --> UNSIGNED_FLOAT
>
> 15 --> UNSIGNED_DOUBLE
>
> 18 --> UNSIGNED_TIME
>
> 19 --> UNSIGNED_DATE
>
> 19 --> UNSIGNED_TIMESTAMP
>
>
>
> As you can see I am actually getting the same value for UNSIGNED_DATE and
> UNSIGNED_TIMESTAMP, is this intended? Or am I getting incorrect
> information.
>
>
>
> Thanks,
>
>
>
> Jamie
>