calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Muhammad Gelbana <m.gelb...@gmail.com>
Subject Re: Pluggable JDBC types
Date Thu, 06 Jun 2019 21:05:25 GMT
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 <zabetak@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.gelbana@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 <hhlai1990@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.gelbana@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
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message