[CALCITE-3200] Add TEXT Data Type

[ambition119]

fix issue CALCITE-3200

1. SQL Server, Mysql, Oracle support TEXT data type.
2. java.sql.Types LONGVARCHAR is TEXT.

[XuQianJin-Stars]

hi @ambition119 Thank you very much for your PR contribution. I have a little suggestion, can you add TEXT type in SqlTypeFixture and add TEXT type test in SqlTypeUtilTest.

[ambition119]

@XuQianJin-Stars @danny0405 Issue says the TEXT can be considered a user defined type and that we shouldn't modify the parser. so then my PR is not suitable, maybe I don't need to improve the code. thanks.

[danny0405]

@XuQianJin-Stars @danny0405 Issue says the TEXT can be considered a user defined type and that we shouldn't modify the parser. so then my PR is not suitable, maybe I don't need to improve the code. thanks.

Thanks for you PR @ambition119 , add a new type to calcite-core is really a huge work, it will affect the type assignment rules, the type infer(operand types and return types), so a more safer and lightweight way it to use a alias for type VARCHAR which is a more implementable solution.

Another reason is that the TEXT type does not belong to the sql standard, so add it to our exists standard types are not that necessary.

I do approve of you to add a sql dialect data type if we have a way to make it pluggable and have a clear interface with which user can switch to.

[ambition119]

@XuQianJin-Stars @danny0405 Issue says the TEXT can be considered a user defined type and that we shouldn't modify the parser. so then my PR is not suitable, maybe I don't need to improve the code. thanks.

Thanks for you PR @ambition119 , add a new type to calcite-core is really a huge work, it will affect the type assignment rules, the type infer(operand types and return types), so a more safer and lightweight way it to use a alias for type VARCHAR which is a more implementable solution.

Another reason is that the TEXT type does not belong to the sql standard, so add it to our exists standard types are not that necessary.

I do approve of you to add a sql dialect data type if we have a way to make it pluggable and have a clear interface with which user can switch to.

ok, thanks.

[ambition119]

@danny0405 sorry, I not find through add a sql dialect data type or make it pluggable and have a clear interface. Can you give me some suggestions? thanks.

[danny0405]

@danny0405 sorry, I not find through add a sql dialect data type or make it pluggable and have a clear interface. Can you give me some suggestions? thanks.

I'm sorry that the data type in Calcite is not pluggable now, actually it is hard to make it pluggable because data type can be touched everywhere, from the sql query parse to sql-to-rel conversion and the planning phrase.

In some engines like Apache Flink, we have our timeAttribute type as a sub-class of Timestamp type, then we can inherit the Timestamp type's type inference, the type precedence, the type assignment and etc. But we rarely to extend the core data types(make fresh new one).

[XuQianJin-Stars]

@danny0405 It is true that the impact of the changes to the underlying data types is indeed large.

[julianhyde]

I'm sorry that the data type in Calcite is not pluggable now

I’ll modify that statement slightly. I’m sorry that data types are not fully pluggable.

But we’ve done a lot of work on user-defined types already, and this could be an opportunity to do a bit more.