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
