calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <jh...@apache.org>
Subject Re: Pluggable JDBC types
Date Mon, 03 Jun 2019 07:59:23 GMT
User-defined types are probably the way to go.

> On Jun 2, 2019, at 8:28 PM, Muhammad Gelbana <m.gelbana@gmail.com> wrote:
> 
> That was my first attempt and it worked, but Julian pointed out that I can
> support a type without modifying the parser (which I prefer) but I couldn't
> get it to return the column type name as I wish.
> 
> Thanks,
> Gelbana
> 
> 
> On Mon, Jun 3, 2019 at 3:13 AM Yuzhao Chen <yuzhao.cyz@gmail.com> wrote:
> 
>> You don’t need to, just define a new type name in parser[1] and translate
>> it to VARCHAR is okey.
>> 
>> [1]
>> https://github.com/apache/calcite/blob/b0e83c469ff57257c1ea621ff943ca76f626a9b7/server/src/main/codegen/config.fmpp#L375
>> 
>> Best,
>> Danny Chan
>> 在 2019年6月3日 +0800 AM6:09,Muhammad Gelbana <m.gelbana@gmail.com>,写道:
>>> That I understand now. But how can I support casting to TEXT and having
>> the
>>> returned column type name as TEXT (ie. Not VARCHAR) ?
>>> 
>>> Thanks,
>>> Gelbana
>>> 
>>> 
>>> On Sun, Jun 2, 2019 at 7:41 PM Julian Hyde <jhyde@apache.org> wrote:
>>> 
>>>> The parser should only parse, not validate. This is a very important
>>>> organizing principle for the parser.
>>>> 
>>>> If I write “x :: text” or “x :: foo” it is up to the type system
>>>> (implemented in the validator and elsewhere) to figure out whether
>> “text”
>>>> or “foo” are valid types.
>>>> 
>>>> Logically, “x :: foo” is the same as “CAST(x AS foo)”. The parser
>> should
>>>> produce the same SqlCall in both cases. Then the parser’s job is done.
>>>> 
>>>> Julian
>>>> 
>>>> 
>>>>> On Jun 2, 2019, at 6:42 AM, Muhammad Gelbana <m.gelbana@gmail.com>
>>>> wrote:
>>>>> 
>>>>> I'm trying to support the PostgreSQL TEXT type[1]. It's basically a
>>>> VARCHAR.
>>>>> 
>>>>> As Julian mentioned in his comment on Jira, I don't need to define a
>>>>> keyword to achieve what I need so I tried exploring that and here is
>>>> what I
>>>>> observed so far:
>>>>> 
>>>>> 1. If I define a new keyword in the parser, I face no trouble
>> whatsoever
>>>>> except for the numerous wiring I need to do for RexToLixTranslator,
>>>>> JavaTypeFactoryImpl, SqlTypeAssignmentRules and SqlTypeName. I won't
>> be
>>>>> suprised if I'm missing anything but doing what I did at first
>> managed to
>>>>> get my queries through.
>>>>> 
>>>>> 2. If I define the type by plugging it in through the root schema, I
>> face
>>>>> two problems: a) The field cannot be declared as nullable because the
>>>> query
>>>>> I'm using for testing gets data from (VALUES()) which doesn't produce
>>>> null
>>>>> values, so an exception is thrown. b) The returned column type name
>> is
>>>>> VARCHAR (although I delcared the new plugged type name to be TEXT),
>> the
>>>>> returned type number is valid though (Types.VARCHAR = 12)
>>>>> 
>>>>> I think I'm doing something wrong that causes (2.a) but (2.b) seems a
>>>> like
>>>>> a bug to me. What do you think ?
>>>>> 
>>>>> [1] https://issues.apache.org/jira/browse/CALCITE-3108
>>>>> 
>>>>> Thanks,
>>>>> Gelbana
>>>> 
>>>> 
>> 


Mime
View raw message