You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by Muhammad Gelbana <m....@gmail.com> on 2019/06/02 13:42:44 UTC
Pluggable JDBC types
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
Re: Pluggable JDBC types
Posted by Muhammad Gelbana <m....@gmail.com>.
I believe you're correct. Thanks a lot for your help.
Thanks,
Gelbana
On Fri, Jun 21, 2019 at 3:51 PM Stamatis Zampetakis <za...@gmail.com>
wrote:
> For the use-case that you described, I think what needs to be changed is in
> CalcitePrepareImpl#getTypeName [1].
> Possibly instead of using RelDataType#getSqlTypeName we should use
> RelDataType#getSqlIdentifier [2].
>
> [1]
>
> https://github.com/apache/calcite/blob/4e89fddab415a1e04b82c7d69960e399f608949f/core/src/main/java/org/apache/calcite/prepare/CalcitePrepareImpl.java#L829
> [2]
>
> https://github.com/apache/calcite/blob/4e89fddab415a1e04b82c7d69960e399f608949f/core/src/main/java/org/apache/calcite/rel/type/RelDataType.java#L200
>
> Best,
> Stamatis
>
> On Thu, Jun 6, 2019 at 11:05 PM Muhammad Gelbana <m....@gmail.com>
> wrote:
>
> > You're absolutely right. User-defined types should be the way to go. I
> > believe it needs enhancement though, only to customize the returned
> column
> > type name as I mentioned here[1]
> >
> > [1]
> >
> >
> https://issues.apache.org/jira/browse/CALCITE-3108?focusedCommentId=16857993&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16857993
> >
> > Thanks,
> > Gelbana
> >
> >
> > On Thu, Jun 6, 2019 at 3:00 PM Stamatis Zampetakis <za...@gmail.com>
> > wrote:
> >
> > > I see but I am not sure SqlTypeName is the way to go.
> > >
> > > Postgres has many built-in types [1] which do not appear in this
> > > enumeration.
> > > Other DBMS have also their own built-in types.
> > > Adding every possible type in SqlTypeName does not seem right.
> > >
> > > Unfortunately, I don't know what's the best way to proceed.
> > >
> > > [1] https://www.postgresql.org/docs/11/datatype.html
> > >
> > >
> > >
> > > On Tue, Jun 4, 2019 at 7:39 PM Muhammad Gelbana <m....@gmail.com>
> > > wrote:
> > >
> > > > The only difference I need to achieve while handling both types, is
> the
> > > > returned column type name
> > (ResultSet.getMetaData().getColumnTypeName(int
> > > > index)).
> > > > The returned value is VARCHAR even if the column type is a user
> defined
> > > > type with the alias TEXT.
> > > >
> > > > While getting the column type name using a real PostgreSQL connection
> > > for a
> > > > TEXT column, is TEXT, not VARCHAR.
> > > >
> > > > Thanks,
> > > > Gelbana
> > > >
> > > >
> > > > On Tue, Jun 4, 2019 at 6:23 PM Stamatis Zampetakis <
> zabetak@gmail.com>
> > > > wrote:
> > > >
> > > > > I am not sure what problem exactly we are trying to solve here
> (sorry
> > > for
> > > > > that).
> > > > > From what I understood so far the requirement is to introduce a new
> > > > > built-in SQL type (i.e., TEXT).
> > > > > However, I am still trying to understand why do we need this.
> > > > > Are we going to treat TEXT and VARCHAR differently?
> > > > >
> > > > > On Tue, Jun 4, 2019 at 5:18 PM Muhammad Gelbana <
> m.gelbana@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > Thanks Lai, I beleive your analysis is correct.
> > > > > >
> > > > > > Which brings up another question:
> > > > > > Is it ok if we add support for what I'm trying to do here ? I can
> > > > gladly
> > > > > > work on that but I need to know if it will be accepted.
> > > > > >
> > > > > > Thanks,
> > > > > > Gelbana
> > > > > >
> > > > > >
> > > > > > On Tue, Jun 4, 2019 at 8:38 AM Lai Zhou <hh...@gmail.com>
> > wrote:
> > > > > >
> > > > > > > @Muhammad Gelbana，I think you just register an alias-name
> 'TEXT'
> > > for
> > > > > the
> > > > > > > SqlType 'VARCHAR'.
> > > > > > > The parser did the right thing here, see
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/calcite/blob/9721283bd0ce46a337f51a3691585cca8003e399/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L1566
> > > > > > > When the parser encountered a 'text' SqlIdentifier, it would
> get
> > > the
> > > > > type
> > > > > > > from the rootSchema, the type was SqlTypeName.VARCHAR here ,
> that
> > > you
> > > > > > > registered before.
> > > > > > > If you really need a new sqlType named 'text' rather than an
> > > > > alias-name,
> > > > > > I
> > > > > > > guess you need to introduce a new kind of SqlTypeName .
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Muhammad Gelbana <m....@gmail.com> 于2019年6月3日周一 下午6:54写道：
> > > > > > >
> > > > > > > > Is that different from what I mentioned in my Jira comment ?
> > Here
> > > > it
> > > > > is
> > > > > > > > again:
> > > > > > > >
> > > > > > > > Connection connection =
> > > > DriverManager.getConnection("jdbc:calcite:",
> > > > > > > info);
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> connection.unwrap(CalciteConnection.class).getRootSchema().unwrap(CalciteSchema.class).add("
> > > > > > > > *TEXT*", new RelProtoDataType() {
> > > > > > > >
> > > > > > > > @Override
> > > > > > > > public RelDataType apply(RelDataTypeFactory
> > factory)
> > > {
> > > > > > > > return
> > > > > > > >
> > > > >
> > factory.createTypeWithNullability(factory.createJavaType(String.class),
> > > > > > > > false);
> > > > > > > > // return
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> factory.createTypeWithNullability(factory.createSqlType(SqlTypeName.VARCHAR),
> > > > > > > > false); // Has the same effect
> > > > > > > > }
> > > > > > > > });
> > > > > > > >
> > > > > > > > This still returns a column type name of VARCHAR, not *TEXT*.
> > > > > > > >
> > > > > > > > I tried providing the type through the model as the UdtTest
> > does
> > > > but
> > > > > > it's
> > > > > > > > giving me the same output.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Gelbana
> > > > > > > >
> > > > > > > >
> > > > > > > > On Mon, Jun 3, 2019 at 9:59 AM Julian Hyde <jhyde@apache.org
> >
> > > > wrote:
> > > > > > > >
> > > > > > > > > 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
> > > > > > > > > >>>>
> > > > > > > > > >>>>
> > > > > > > > > >>
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Pluggable JDBC types
Posted by Stamatis Zampetakis <za...@gmail.com>.
For the use-case that you described, I think what needs to be changed is in
CalcitePrepareImpl#getTypeName [1].
Possibly instead of using RelDataType#getSqlTypeName we should use
RelDataType#getSqlIdentifier [2].
[1]
https://github.com/apache/calcite/blob/4e89fddab415a1e04b82c7d69960e399f608949f/core/src/main/java/org/apache/calcite/prepare/CalcitePrepareImpl.java#L829
[2]
https://github.com/apache/calcite/blob/4e89fddab415a1e04b82c7d69960e399f608949f/core/src/main/java/org/apache/calcite/rel/type/RelDataType.java#L200
Best,
Stamatis
On Thu, Jun 6, 2019 at 11:05 PM Muhammad Gelbana <m....@gmail.com>
wrote:
> You're absolutely right. User-defined types should be the way to go. I
> believe it needs enhancement though, only to customize the returned column
> type name as I mentioned here[1]
>
> [1]
>
> https://issues.apache.org/jira/browse/CALCITE-3108?focusedCommentId=16857993&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16857993
>
> Thanks,
> Gelbana
>
>
> On Thu, Jun 6, 2019 at 3:00 PM Stamatis Zampetakis <za...@gmail.com>
> wrote:
>
> > I see but I am not sure SqlTypeName is the way to go.
> >
> > Postgres has many built-in types [1] which do not appear in this
> > enumeration.
> > Other DBMS have also their own built-in types.
> > Adding every possible type in SqlTypeName does not seem right.
> >
> > Unfortunately, I don't know what's the best way to proceed.
> >
> > [1] https://www.postgresql.org/docs/11/datatype.html
> >
> >
> >
> > On Tue, Jun 4, 2019 at 7:39 PM Muhammad Gelbana <m....@gmail.com>
> > wrote:
> >
> > > The only difference I need to achieve while handling both types, is the
> > > returned column type name
> (ResultSet.getMetaData().getColumnTypeName(int
> > > index)).
> > > The returned value is VARCHAR even if the column type is a user defined
> > > type with the alias TEXT.
> > >
> > > While getting the column type name using a real PostgreSQL connection
> > for a
> > > TEXT column, is TEXT, not VARCHAR.
> > >
> > > Thanks,
> > > Gelbana
> > >
> > >
> > > On Tue, Jun 4, 2019 at 6:23 PM Stamatis Zampetakis <za...@gmail.com>
> > > wrote:
> > >
> > > > I am not sure what problem exactly we are trying to solve here (sorry
> > for
> > > > that).
> > > > From what I understood so far the requirement is to introduce a new
> > > > built-in SQL type (i.e., TEXT).
> > > > However, I am still trying to understand why do we need this.
> > > > Are we going to treat TEXT and VARCHAR differently?
> > > >
> > > > On Tue, Jun 4, 2019 at 5:18 PM Muhammad Gelbana <m.gelbana@gmail.com
> >
> > > > wrote:
> > > >
> > > > > Thanks Lai, I beleive your analysis is correct.
> > > > >
> > > > > Which brings up another question:
> > > > > Is it ok if we add support for what I'm trying to do here ? I can
> > > gladly
> > > > > work on that but I need to know if it will be accepted.
> > > > >
> > > > > Thanks,
> > > > > Gelbana
> > > > >
> > > > >
> > > > > On Tue, Jun 4, 2019 at 8:38 AM Lai Zhou <hh...@gmail.com>
> wrote:
> > > > >
> > > > > > @Muhammad Gelbana，I think you just register an alias-name 'TEXT'
> > for
> > > > the
> > > > > > SqlType 'VARCHAR'.
> > > > > > The parser did the right thing here, see
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/calcite/blob/9721283bd0ce46a337f51a3691585cca8003e399/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L1566
> > > > > > When the parser encountered a 'text' SqlIdentifier, it would get
> > the
> > > > type
> > > > > > from the rootSchema, the type was SqlTypeName.VARCHAR here , that
> > you
> > > > > > registered before.
> > > > > > If you really need a new sqlType named 'text' rather than an
> > > > alias-name,
> > > > > I
> > > > > > guess you need to introduce a new kind of SqlTypeName .
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Muhammad Gelbana <m....@gmail.com> 于2019年6月3日周一 下午6:54写道：
> > > > > >
> > > > > > > Is that different from what I mentioned in my Jira comment ?
> Here
> > > it
> > > > is
> > > > > > > again:
> > > > > > >
> > > > > > > Connection connection =
> > > DriverManager.getConnection("jdbc:calcite:",
> > > > > > info);
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> connection.unwrap(CalciteConnection.class).getRootSchema().unwrap(CalciteSchema.class).add("
> > > > > > > *TEXT*", new RelProtoDataType() {
> > > > > > >
> > > > > > > @Override
> > > > > > > public RelDataType apply(RelDataTypeFactory
> factory)
> > {
> > > > > > > return
> > > > > > >
> > > >
> factory.createTypeWithNullability(factory.createJavaType(String.class),
> > > > > > > false);
> > > > > > > // return
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> factory.createTypeWithNullability(factory.createSqlType(SqlTypeName.VARCHAR),
> > > > > > > false); // Has the same effect
> > > > > > > }
> > > > > > > });
> > > > > > >
> > > > > > > This still returns a column type name of VARCHAR, not *TEXT*.
> > > > > > >
> > > > > > > I tried providing the type through the model as the UdtTest
> does
> > > but
> > > > > it's
> > > > > > > giving me the same output.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Gelbana
> > > > > > >
> > > > > > >
> > > > > > > On Mon, Jun 3, 2019 at 9:59 AM Julian Hyde <jh...@apache.org>
> > > wrote:
> > > > > > >
> > > > > > > > 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
> > > > > > > > >>>>
> > > > > > > > >>>>
> > > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Pluggable JDBC types
Posted by Muhammad Gelbana <m....@gmail.com>.
You're absolutely right. User-defined types should be the way to go. I
believe it needs enhancement though, only to customize the returned column
type name as I mentioned here[1]
[1]
https://issues.apache.org/jira/browse/CALCITE-3108?focusedCommentId=16857993&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16857993
Thanks,
Gelbana
On Thu, Jun 6, 2019 at 3:00 PM Stamatis Zampetakis <za...@gmail.com>
wrote:
> I see but I am not sure SqlTypeName is the way to go.
>
> Postgres has many built-in types [1] which do not appear in this
> enumeration.
> Other DBMS have also their own built-in types.
> Adding every possible type in SqlTypeName does not seem right.
>
> Unfortunately, I don't know what's the best way to proceed.
>
> [1] https://www.postgresql.org/docs/11/datatype.html
>
>
>
> On Tue, Jun 4, 2019 at 7:39 PM Muhammad Gelbana <m....@gmail.com>
> wrote:
>
> > The only difference I need to achieve while handling both types, is the
> > returned column type name (ResultSet.getMetaData().getColumnTypeName(int
> > index)).
> > The returned value is VARCHAR even if the column type is a user defined
> > type with the alias TEXT.
> >
> > While getting the column type name using a real PostgreSQL connection
> for a
> > TEXT column, is TEXT, not VARCHAR.
> >
> > Thanks,
> > Gelbana
> >
> >
> > On Tue, Jun 4, 2019 at 6:23 PM Stamatis Zampetakis <za...@gmail.com>
> > wrote:
> >
> > > I am not sure what problem exactly we are trying to solve here (sorry
> for
> > > that).
> > > From what I understood so far the requirement is to introduce a new
> > > built-in SQL type (i.e., TEXT).
> > > However, I am still trying to understand why do we need this.
> > > Are we going to treat TEXT and VARCHAR differently?
> > >
> > > On Tue, Jun 4, 2019 at 5:18 PM Muhammad Gelbana <m....@gmail.com>
> > > wrote:
> > >
> > > > Thanks Lai, I beleive your analysis is correct.
> > > >
> > > > Which brings up another question:
> > > > Is it ok if we add support for what I'm trying to do here ? I can
> > gladly
> > > > work on that but I need to know if it will be accepted.
> > > >
> > > > Thanks,
> > > > Gelbana
> > > >
> > > >
> > > > On Tue, Jun 4, 2019 at 8:38 AM Lai Zhou <hh...@gmail.com> wrote:
> > > >
> > > > > @Muhammad Gelbana，I think you just register an alias-name 'TEXT'
> for
> > > the
> > > > > SqlType 'VARCHAR'.
> > > > > The parser did the right thing here, see
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/calcite/blob/9721283bd0ce46a337f51a3691585cca8003e399/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L1566
> > > > > When the parser encountered a 'text' SqlIdentifier, it would get
> the
> > > type
> > > > > from the rootSchema, the type was SqlTypeName.VARCHAR here , that
> you
> > > > > registered before.
> > > > > If you really need a new sqlType named 'text' rather than an
> > > alias-name,
> > > > I
> > > > > guess you need to introduce a new kind of SqlTypeName .
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Muhammad Gelbana <m....@gmail.com> 于2019年6月3日周一 下午6:54写道：
> > > > >
> > > > > > Is that different from what I mentioned in my Jira comment ? Here
> > it
> > > is
> > > > > > again:
> > > > > >
> > > > > > Connection connection =
> > DriverManager.getConnection("jdbc:calcite:",
> > > > > info);
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> connection.unwrap(CalciteConnection.class).getRootSchema().unwrap(CalciteSchema.class).add("
> > > > > > *TEXT*", new RelProtoDataType() {
> > > > > >
> > > > > > @Override
> > > > > > public RelDataType apply(RelDataTypeFactory factory)
> {
> > > > > > return
> > > > > >
> > > factory.createTypeWithNullability(factory.createJavaType(String.class),
> > > > > > false);
> > > > > > // return
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> factory.createTypeWithNullability(factory.createSqlType(SqlTypeName.VARCHAR),
> > > > > > false); // Has the same effect
> > > > > > }
> > > > > > });
> > > > > >
> > > > > > This still returns a column type name of VARCHAR, not *TEXT*.
> > > > > >
> > > > > > I tried providing the type through the model as the UdtTest does
> > but
> > > > it's
> > > > > > giving me the same output.
> > > > > >
> > > > > > Thanks,
> > > > > > Gelbana
> > > > > >
> > > > > >
> > > > > > On Mon, Jun 3, 2019 at 9:59 AM Julian Hyde <jh...@apache.org>
> > wrote:
> > > > > >
> > > > > > > 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
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Pluggable JDBC types
Posted by Stamatis Zampetakis <za...@gmail.com>.
I see but I am not sure SqlTypeName is the way to go.
Postgres has many built-in types [1] which do not appear in this
enumeration.
Other DBMS have also their own built-in types.
Adding every possible type in SqlTypeName does not seem right.
Unfortunately, I don't know what's the best way to proceed.
[1] https://www.postgresql.org/docs/11/datatype.html
On Tue, Jun 4, 2019 at 7:39 PM Muhammad Gelbana <m....@gmail.com> wrote:
> The only difference I need to achieve while handling both types, is the
> returned column type name (ResultSet.getMetaData().getColumnTypeName(int
> index)).
> The returned value is VARCHAR even if the column type is a user defined
> type with the alias TEXT.
>
> While getting the column type name using a real PostgreSQL connection for a
> TEXT column, is TEXT, not VARCHAR.
>
> Thanks,
> Gelbana
>
>
> On Tue, Jun 4, 2019 at 6:23 PM Stamatis Zampetakis <za...@gmail.com>
> wrote:
>
> > I am not sure what problem exactly we are trying to solve here (sorry for
> > that).
> > From what I understood so far the requirement is to introduce a new
> > built-in SQL type (i.e., TEXT).
> > However, I am still trying to understand why do we need this.
> > Are we going to treat TEXT and VARCHAR differently?
> >
> > On Tue, Jun 4, 2019 at 5:18 PM Muhammad Gelbana <m....@gmail.com>
> > wrote:
> >
> > > Thanks Lai, I beleive your analysis is correct.
> > >
> > > Which brings up another question:
> > > Is it ok if we add support for what I'm trying to do here ? I can
> gladly
> > > work on that but I need to know if it will be accepted.
> > >
> > > Thanks,
> > > Gelbana
> > >
> > >
> > > On Tue, Jun 4, 2019 at 8:38 AM Lai Zhou <hh...@gmail.com> wrote:
> > >
> > > > @Muhammad Gelbana，I think you just register an alias-name 'TEXT' for
> > the
> > > > SqlType 'VARCHAR'.
> > > > The parser did the right thing here, see
> > > >
> > > >
> > >
> >
> https://github.com/apache/calcite/blob/9721283bd0ce46a337f51a3691585cca8003e399/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L1566
> > > > When the parser encountered a 'text' SqlIdentifier, it would get the
> > type
> > > > from the rootSchema, the type was SqlTypeName.VARCHAR here , that you
> > > > registered before.
> > > > If you really need a new sqlType named 'text' rather than an
> > alias-name,
> > > I
> > > > guess you need to introduce a new kind of SqlTypeName .
> > > >
> > > >
> > > >
> > > >
> > > > Muhammad Gelbana <m....@gmail.com> 于2019年6月3日周一 下午6:54写道：
> > > >
> > > > > Is that different from what I mentioned in my Jira comment ? Here
> it
> > is
> > > > > again:
> > > > >
> > > > > Connection connection =
> DriverManager.getConnection("jdbc:calcite:",
> > > > info);
> > > > >
> > > > >
> > > >
> > >
> >
> connection.unwrap(CalciteConnection.class).getRootSchema().unwrap(CalciteSchema.class).add("
> > > > > *TEXT*", new RelProtoDataType() {
> > > > >
> > > > > @Override
> > > > > public RelDataType apply(RelDataTypeFactory factory) {
> > > > > return
> > > > >
> > factory.createTypeWithNullability(factory.createJavaType(String.class),
> > > > > false);
> > > > > // return
> > > > >
> > > > >
> > > >
> > >
> >
> factory.createTypeWithNullability(factory.createSqlType(SqlTypeName.VARCHAR),
> > > > > false); // Has the same effect
> > > > > }
> > > > > });
> > > > >
> > > > > This still returns a column type name of VARCHAR, not *TEXT*.
> > > > >
> > > > > I tried providing the type through the model as the UdtTest does
> but
> > > it's
> > > > > giving me the same output.
> > > > >
> > > > > Thanks,
> > > > > Gelbana
> > > > >
> > > > >
> > > > > On Mon, Jun 3, 2019 at 9:59 AM Julian Hyde <jh...@apache.org>
> wrote:
> > > > >
> > > > > > 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
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Pluggable JDBC types
Posted by Muhammad Gelbana <m....@gmail.com>.
The only difference I need to achieve while handling both types, is the
returned column type name (ResultSet.getMetaData().getColumnTypeName(int
index)).
The returned value is VARCHAR even if the column type is a user defined
type with the alias TEXT.
While getting the column type name using a real PostgreSQL connection for a
TEXT column, is TEXT, not VARCHAR.
Thanks,
Gelbana
On Tue, Jun 4, 2019 at 6:23 PM Stamatis Zampetakis <za...@gmail.com>
wrote:
> I am not sure what problem exactly we are trying to solve here (sorry for
> that).
> From what I understood so far the requirement is to introduce a new
> built-in SQL type (i.e., TEXT).
> However, I am still trying to understand why do we need this.
> Are we going to treat TEXT and VARCHAR differently?
>
> On Tue, Jun 4, 2019 at 5:18 PM Muhammad Gelbana <m....@gmail.com>
> wrote:
>
> > Thanks Lai, I beleive your analysis is correct.
> >
> > Which brings up another question:
> > Is it ok if we add support for what I'm trying to do here ? I can gladly
> > work on that but I need to know if it will be accepted.
> >
> > Thanks,
> > Gelbana
> >
> >
> > On Tue, Jun 4, 2019 at 8:38 AM Lai Zhou <hh...@gmail.com> wrote:
> >
> > > @Muhammad Gelbana，I think you just register an alias-name 'TEXT' for
> the
> > > SqlType 'VARCHAR'.
> > > The parser did the right thing here, see
> > >
> > >
> >
> https://github.com/apache/calcite/blob/9721283bd0ce46a337f51a3691585cca8003e399/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L1566
> > > When the parser encountered a 'text' SqlIdentifier, it would get the
> type
> > > from the rootSchema, the type was SqlTypeName.VARCHAR here , that you
> > > registered before.
> > > If you really need a new sqlType named 'text' rather than an
> alias-name,
> > I
> > > guess you need to introduce a new kind of SqlTypeName .
> > >
> > >
> > >
> > >
> > > Muhammad Gelbana <m....@gmail.com> 于2019年6月3日周一 下午6:54写道：
> > >
> > > > Is that different from what I mentioned in my Jira comment ? Here it
> is
> > > > again:
> > > >
> > > > Connection connection = DriverManager.getConnection("jdbc:calcite:",
> > > info);
> > > >
> > > >
> > >
> >
> connection.unwrap(CalciteConnection.class).getRootSchema().unwrap(CalciteSchema.class).add("
> > > > *TEXT*", new RelProtoDataType() {
> > > >
> > > > @Override
> > > > public RelDataType apply(RelDataTypeFactory factory) {
> > > > return
> > > >
> factory.createTypeWithNullability(factory.createJavaType(String.class),
> > > > false);
> > > > // return
> > > >
> > > >
> > >
> >
> factory.createTypeWithNullability(factory.createSqlType(SqlTypeName.VARCHAR),
> > > > false); // Has the same effect
> > > > }
> > > > });
> > > >
> > > > This still returns a column type name of VARCHAR, not *TEXT*.
> > > >
> > > > I tried providing the type through the model as the UdtTest does but
> > it's
> > > > giving me the same output.
> > > >
> > > > Thanks,
> > > > Gelbana
> > > >
> > > >
> > > > On Mon, Jun 3, 2019 at 9:59 AM Julian Hyde <jh...@apache.org> wrote:
> > > >
> > > > > 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 <jh...@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
> > > > > >>>>
> > > > > >>>>
> > > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Pluggable JDBC types
Posted by Stamatis Zampetakis <za...@gmail.com>.
I am not sure what problem exactly we are trying to solve here (sorry for
that).
From what I understood so far the requirement is to introduce a new
built-in SQL type (i.e., TEXT).
However, I am still trying to understand why do we need this.
Are we going to treat TEXT and VARCHAR differently?
On Tue, Jun 4, 2019 at 5:18 PM Muhammad Gelbana <m....@gmail.com> wrote:
> Thanks Lai, I beleive your analysis is correct.
>
> Which brings up another question:
> Is it ok if we add support for what I'm trying to do here ? I can gladly
> work on that but I need to know if it will be accepted.
>
> Thanks,
> Gelbana
>
>
> On Tue, Jun 4, 2019 at 8:38 AM Lai Zhou <hh...@gmail.com> wrote:
>
> > @Muhammad Gelbana，I think you just register an alias-name 'TEXT' for the
> > SqlType 'VARCHAR'.
> > The parser did the right thing here, see
> >
> >
> https://github.com/apache/calcite/blob/9721283bd0ce46a337f51a3691585cca8003e399/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L1566
> > When the parser encountered a 'text' SqlIdentifier, it would get the type
> > from the rootSchema, the type was SqlTypeName.VARCHAR here , that you
> > registered before.
> > If you really need a new sqlType named 'text' rather than an alias-name,
> I
> > guess you need to introduce a new kind of SqlTypeName .
> >
> >
> >
> >
> > Muhammad Gelbana <m....@gmail.com> 于2019年6月3日周一 下午6:54写道：
> >
> > > Is that different from what I mentioned in my Jira comment ? Here it is
> > > again:
> > >
> > > Connection connection = DriverManager.getConnection("jdbc:calcite:",
> > info);
> > >
> > >
> >
> connection.unwrap(CalciteConnection.class).getRootSchema().unwrap(CalciteSchema.class).add("
> > > *TEXT*", new RelProtoDataType() {
> > >
> > > @Override
> > > public RelDataType apply(RelDataTypeFactory factory) {
> > > return
> > > factory.createTypeWithNullability(factory.createJavaType(String.class),
> > > false);
> > > // return
> > >
> > >
> >
> factory.createTypeWithNullability(factory.createSqlType(SqlTypeName.VARCHAR),
> > > false); // Has the same effect
> > > }
> > > });
> > >
> > > This still returns a column type name of VARCHAR, not *TEXT*.
> > >
> > > I tried providing the type through the model as the UdtTest does but
> it's
> > > giving me the same output.
> > >
> > > Thanks,
> > > Gelbana
> > >
> > >
> > > On Mon, Jun 3, 2019 at 9:59 AM Julian Hyde <jh...@apache.org> wrote:
> > >
> > > > User-defined types are probably the way to go.
> > > >
> > > > > On Jun 2, 2019, at 8:28 PM, Muhammad Gelbana <m....@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 <yu...@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 <jh...@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
> > > > >>>>
> > > > >>>>
> > > > >>
> > > >
> > > >
> > >
> >
>
Re: Pluggable JDBC types
Posted by Muhammad Gelbana <m....@gmail.com>.
Thanks Lai, I beleive your analysis is correct.
Which brings up another question:
Is it ok if we add support for what I'm trying to do here ? I can gladly
work on that but I need to know if it will be accepted.
Thanks,
Gelbana
On Tue, Jun 4, 2019 at 8:38 AM Lai Zhou <hh...@gmail.com> wrote:
> @Muhammad Gelbana，I think you just register an alias-name 'TEXT' for the
> SqlType 'VARCHAR'.
> The parser did the right thing here, see
>
> https://github.com/apache/calcite/blob/9721283bd0ce46a337f51a3691585cca8003e399/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L1566
> When the parser encountered a 'text' SqlIdentifier, it would get the type
> from the rootSchema, the type was SqlTypeName.VARCHAR here , that you
> registered before.
> If you really need a new sqlType named 'text' rather than an alias-name, I
> guess you need to introduce a new kind of SqlTypeName .
>
>
>
>
> Muhammad Gelbana <m....@gmail.com> 于2019年6月3日周一 下午6:54写道：
>
> > Is that different from what I mentioned in my Jira comment ? Here it is
> > again:
> >
> > Connection connection = DriverManager.getConnection("jdbc:calcite:",
> info);
> >
> >
> connection.unwrap(CalciteConnection.class).getRootSchema().unwrap(CalciteSchema.class).add("
> > *TEXT*", new RelProtoDataType() {
> >
> > @Override
> > public RelDataType apply(RelDataTypeFactory factory) {
> > return
> > factory.createTypeWithNullability(factory.createJavaType(String.class),
> > false);
> > // return
> >
> >
> factory.createTypeWithNullability(factory.createSqlType(SqlTypeName.VARCHAR),
> > false); // Has the same effect
> > }
> > });
> >
> > This still returns a column type name of VARCHAR, not *TEXT*.
> >
> > I tried providing the type through the model as the UdtTest does but it's
> > giving me the same output.
> >
> > Thanks,
> > Gelbana
> >
> >
> > On Mon, Jun 3, 2019 at 9:59 AM Julian Hyde <jh...@apache.org> wrote:
> >
> > > User-defined types are probably the way to go.
> > >
> > > > On Jun 2, 2019, at 8:28 PM, Muhammad Gelbana <m....@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 <yu...@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....@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 <jh...@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
> > > >>>>
> > > >>>>
> > > >>
> > >
> > >
> >
>
Re: Pluggable JDBC types
Posted by Lai Zhou <hh...@gmail.com>.
@Muhammad Gelbana，I think you just register an alias-name 'TEXT' for the
SqlType 'VARCHAR'.
The parser did the right thing here, see
https://github.com/apache/calcite/blob/9721283bd0ce46a337f51a3691585cca8003e399/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L1566
When the parser encountered a 'text' SqlIdentifier, it would get the type
from the rootSchema, the type was SqlTypeName.VARCHAR here , that you
registered before.
If you really need a new sqlType named 'text' rather than an alias-name, I
guess you need to introduce a new kind of SqlTypeName .
Muhammad Gelbana <m....@gmail.com> 于2019年6月3日周一 下午6:54写道：
> Is that different from what I mentioned in my Jira comment ? Here it is
> again:
>
> Connection connection = DriverManager.getConnection("jdbc:calcite:", info);
>
> connection.unwrap(CalciteConnection.class).getRootSchema().unwrap(CalciteSchema.class).add("
> *TEXT*", new RelProtoDataType() {
>
> @Override
> public RelDataType apply(RelDataTypeFactory factory) {
> return
> factory.createTypeWithNullability(factory.createJavaType(String.class),
> false);
> // return
>
> factory.createTypeWithNullability(factory.createSqlType(SqlTypeName.VARCHAR),
> false); // Has the same effect
> }
> });
>
> This still returns a column type name of VARCHAR, not *TEXT*.
>
> I tried providing the type through the model as the UdtTest does but it's
> giving me the same output.
>
> Thanks,
> Gelbana
>
>
> On Mon, Jun 3, 2019 at 9:59 AM Julian Hyde <jh...@apache.org> wrote:
>
> > User-defined types are probably the way to go.
> >
> > > On Jun 2, 2019, at 8:28 PM, Muhammad Gelbana <m....@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 <yu...@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....@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 <jh...@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....@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
> > >>>>
> > >>>>
> > >>
> >
> >
>
Re: Pluggable JDBC types
Posted by Muhammad Gelbana <m....@gmail.com>.
Is that different from what I mentioned in my Jira comment ? Here it is
again:
Connection connection = DriverManager.getConnection("jdbc:calcite:", info);
connection.unwrap(CalciteConnection.class).getRootSchema().unwrap(CalciteSchema.class).add("
*TEXT*", new RelProtoDataType() {
@Override
public RelDataType apply(RelDataTypeFactory factory) {
return
factory.createTypeWithNullability(factory.createJavaType(String.class),
false);
// return
factory.createTypeWithNullability(factory.createSqlType(SqlTypeName.VARCHAR),
false); // Has the same effect
}
});
This still returns a column type name of VARCHAR, not *TEXT*.
I tried providing the type through the model as the UdtTest does but it's
giving me the same output.
Thanks,
Gelbana
On Mon, Jun 3, 2019 at 9:59 AM Julian Hyde <jh...@apache.org> wrote:
> User-defined types are probably the way to go.
>
> > On Jun 2, 2019, at 8:28 PM, Muhammad Gelbana <m....@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 <yu...@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....@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 <jh...@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....@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
> >>>>
> >>>>
> >>
>
>
Re: Pluggable JDBC types
Posted by Julian Hyde <jh...@apache.org>.
User-defined types are probably the way to go.
> On Jun 2, 2019, at 8:28 PM, Muhammad Gelbana <m....@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 <yu...@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....@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 <jh...@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....@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
>>>>
>>>>
>>
Re: Pluggable JDBC types
Posted by Muhammad Gelbana <m....@gmail.com>.
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 <yu...@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....@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 <jh...@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....@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
> > >
> > >
>
Re: Pluggable JDBC types
Posted by Yuzhao Chen <yu...@gmail.com>.
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....@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 <jh...@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....@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
> >
> >
Re: Pluggable JDBC types
Posted by Muhammad Gelbana <m....@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 <jh...@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....@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
>
>
Re: Pluggable JDBC types
Posted by Julian Hyde <jh...@apache.org>.
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....@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