I believe you're correct. Thanks a lot for your help. Thanks, Gelbana
On Fri, Jun 21, 2019 at 3:51 PM Stamatis Zampetakis <[email protected]> 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 <[email protected]> > 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 <[email protected]> > > 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 <[email protected]> > > > 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 < > [email protected]> > > > > 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 < > [email protected] > > > > > > > > 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 <[email protected]> > > 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 <[email protected]> 于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 <[email protected] > > > > > > wrote: > > > > > > > > > > > > > > > > > User-defined types are probably the way to go. > > > > > > > > > > > > > > > > > > > On Jun 2, 2019, at 8:28 PM, Muhammad Gelbana < > > > > > [email protected]> > > > > > > > > > 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 < > > > > [email protected] > > > > > > > > > > > > > > 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 < > > > > [email protected] > > > > > > >，写道： > > > > > > > > > >>> 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 < > > > [email protected] > > > > > > > > > > > > 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 < > > > > > > > [email protected]> > > > > > > > > > >>>> 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 > > > > > > > > > >>>> > > > > > > > > > >>>> > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
