I believe you're correct. Thanks a lot for your help.
Thanks,
Gelbana
On Fri, Jun 21, 2019 at 3:51 PM Stamatis Zampetakis
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#getSqlType
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/c
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.
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 proc
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 rea
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
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 wrote:
> @Muhammad Gelbana
@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 t
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() {
@Ov
User-defined types are probably the way to go.
> On Jun 2, 2019, at 8:28 PM, Muhammad Gelbana 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 nam
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 wrote:
> You don’t need to, just de
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 ，写道：
> That I
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 wrote:
> The parser should only parse, not validate. This is a very important
> organizing principle for
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” i
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 trou
15 matches
Mail list logo
