calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <>
Subject Re: Pluggable JDBC types
Date Sun, 02 Jun 2019 17:41:23 GMT
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.


> On Jun 2, 2019, at 6:42 AM, Muhammad Gelbana <> 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]
> Thanks,
> Gelbana

View raw message