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 > >
