[jira] [Commented] (CALCITE-2623) Updating unparseCall() in SqlDialect(s) for dialect specifc SqlNode unparsing
[ https://issues.apache.org/jira/browse/CALCITE-2623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16735588#comment-16735588 ] KrishnaKant Agrawal commented on CALCITE-2623: -- Hi All, If anybody gets the time please review this. > Updating unparseCall() in SqlDialect(s) for dialect specifc SqlNode unparsing > - > > Key: CALCITE-2623 > URL: https://issues.apache.org/jira/browse/CALCITE-2623 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: KrishnaKant Agrawal >Assignee: Julian Hyde >Priority: Minor > Labels: pull-request-available > > Owing to the syntactical differences between Calcite SQL and certain other > Dialects, emulation for SqlNode unparsing needs to be added based on the > Dialect in RelToSqlConcverter. > Saw some code in PostgreSqlDialect which is already doing this. > Changes in other Dialects can follow suit. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2623) Updating unparseCall() in SqlDialect(s) for dialect specifc SqlNode unparsing
[
https://issues.apache.org/jira/browse/CALCITE-2623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723844#comment-16723844
]
KrishnaKant Agrawal commented on CALCITE-2623:
--
{quote}BigQuery has a MOD operator. Why are you adding "%"?
{quote}
I have added it to HiveSqlDialect (Hive does not support MOD), not
BigQuerySqlDialect.
{quote}In standard SQL, UNION accepts either ALL or DISTINCT. DISTINCT is the
default, so people tend to write "UNION" rather than "UNION DISTINCT", even if
they mean the same thing. I'm not sure why you add it BigQuery. Does BigQuery
not support UNION without DISTINCT?
{quote}
Yes, you are right. In BigQuery, with SET OPERATIONS, DISTINCT or ALL keyword
has to be explicitly mentioned for the query to run.
{quote}Let's not switch on operator name. Switch on operator.getKind() if
possible. Better, if you need to use an operator with a non-standard syntax for
a particular dialect, introduce it during RelToSql conversion, and let it
unparse itself. That's usually better than modifying the dialect.
{quote}
For this to be possible, *I need to add SqlKind.POSITION in SqlKind Enum*. As
many functions come under OTHER_FUNCTION, there may be more additions to that
Enum.
{quote}Why did you break the line in "testSelectQueryWithLimitClause"?
{quote}
Will correct it. My Intelij Code Formatter Issues.
{quote}Rather than "sql(query).dialect(HiveSqlDialect.DEFAULT)" use
"sql(query).withHive()". Similarly withBigQuery.
{quote}
Got it, I will correct this.
> Updating unparseCall() in SqlDialect(s) for dialect specifc SqlNode unparsing
> -
>
> Key: CALCITE-2623
> URL: https://issues.apache.org/jira/browse/CALCITE-2623
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: KrishnaKant Agrawal
>Assignee: Julian Hyde
>Priority: Minor
>
> Owing to the syntactical differences between Calcite SQL and certain other
> Dialects, emulation for SqlNode unparsing needs to be added based on the
> Dialect in RelToSqlConcverter.
> Saw some code in PostgreSqlDialect which is already doing this.
> Changes in other Dialects can follow suit.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2623) Updating unparseCall() in SqlDialect(s) for dialect specifc SqlNode unparsing
[
https://issues.apache.org/jira/browse/CALCITE-2623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654638#comment-16654638
]
KrishnaKant Agrawal commented on CALCITE-2623:
--
My Understanding is that all instances of SqlOperator being used while building
a RelNode should come from SqlStdOperatorTable(which is ANSI Compliant I
assume). Now, If this RelNode were to converted to SqlNode it would still have
Calcite Specific Operators Inside it. But when I create SqlString out of it,
the unparseCall() would take care of syntactical differences as mentioned below.
Suppose I want to create a RelNode containing a TRIM operator.
Now, the RelNode that I created will have SqlStdOperatorTable.TRIM inside it.
The SqlOperator's unparse() will have the syntax like TRIM(LEADING from col1)
which is not recognized by the set Dialect(say HIVE for instance).
Hive recognizes LTRIM and RTRIM.
So the unparseCall() inside HiveSqlDialect will take care of this change.
The code in PostgresqlSqlDialect, which made me think of this as something
which is already accepted:-
{code:java}
@Override public void unparseCall(SqlWriter writer, SqlCall call,
int leftPrec, int rightPrec) {
switch (call.getKind()) {
case FLOOR:
if (call.operandCount() != 2) {
super.unparseCall(writer, call, leftPrec, rightPrec);
return;
}
final SqlLiteral timeUnitNode = call.operand(1);
final TimeUnitRange timeUnit =
timeUnitNode.getValueAs(TimeUnitRange.class);
SqlCall call2 = SqlFloorFunction.replaceTimeUnitOperand(call,
timeUnit.name(),
timeUnitNode.getParserPosition());
SqlFloorFunction.unparseDatetimeFunction(writer, call2, "DATE_TRUNC",
false);
break;
default:
super.unparseCall(writer, call, leftPrec, rightPrec);
}
}
{code}
I have created a [PR|https://github.com/apache/calcite/pull/877]. Maybe you can
review that once and see if I am headed in the right direction. I plan to
handle many more Functions/Operators this way.
> Updating unparseCall() in SqlDialect(s) for dialect specifc SqlNode unparsing
> -
>
> Key: CALCITE-2623
> URL: https://issues.apache.org/jira/browse/CALCITE-2623
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: KrishnaKant Agrawal
>Assignee: Julian Hyde
>Priority: Minor
>
> Owing to the syntactical differences between Calcite SQL and certain other
> Dialects, emulation for SqlNode unparsing needs to be added based on the
> Dialect in RelToSqlConcverter.
> Saw some code in PostgreSqlDialect which is already doing this.
> Changes in other Dialects can follow suit.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2623) Updating unparseCall() in SqlDialect(s) for dialect specifc SqlNode unparsing
[
https://issues.apache.org/jira/browse/CALCITE-2623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648579#comment-16648579
]
Julian Hyde commented on CALCITE-2623:
--
Also note that an implementation of {{SqlNode.unparse(SqlWriter, int, int)}}
can call {{SqlWriter.getDialect()}}. This is how identifiers get quoted using
double-quote on Oracle, back-ticks on MySQL etc.
> Updating unparseCall() in SqlDialect(s) for dialect specifc SqlNode unparsing
> -
>
> Key: CALCITE-2623
> URL: https://issues.apache.org/jira/browse/CALCITE-2623
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: KrishnaKant Agrawal
>Assignee: Julian Hyde
>Priority: Minor
>
> Owing to the syntactical differences between Calcite SQL and certain other
> Dialects, emulation for SqlNode unparsing needs to be added based on the
> Dialect in RelToSqlConcverter.
> Saw some code in PostgreSqlDialect which is already doing this.
> Changes in other Dialects can follow suit.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2623) Updating unparseCall() in SqlDialect(s) for dialect specifc SqlNode unparsing
[ https://issues.apache.org/jira/browse/CALCITE-2623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648575#comment-16648575 ] Julian Hyde commented on CALCITE-2623: -- Can you give an example where it currently fails? > Updating unparseCall() in SqlDialect(s) for dialect specifc SqlNode unparsing > - > > Key: CALCITE-2623 > URL: https://issues.apache.org/jira/browse/CALCITE-2623 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: KrishnaKant Agrawal >Assignee: Julian Hyde >Priority: Minor > > Owing to the syntactical differences between Calcite SQL and certain other > Dialects, emulation for SqlNode unparsing needs to be added based on the > Dialect in RelToSqlConcverter. > Saw some code in PostgreSqlDialect which is already doing this. > Changes in other Dialects can follow suit. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2623) Updating unparseCall() in SqlDialect(s) for dialect specifc SqlNode unparsing
[ https://issues.apache.org/jira/browse/CALCITE-2623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16647652#comment-16647652 ] KrishnaKant Agrawal commented on CALCITE-2623: -- Will raise the first PR in a couple of Days. > Updating unparseCall() in SqlDialect(s) for dialect specifc SqlNode unparsing > - > > Key: CALCITE-2623 > URL: https://issues.apache.org/jira/browse/CALCITE-2623 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: KrishnaKant Agrawal >Assignee: Julian Hyde >Priority: Minor > > Owing to the syntactical differences between Calcite SQL and certain other > Dialects, emulation for SqlNode unparsing needs to be added based on the > Dialect in RelToSqlConcverter. > Saw some code in PostgreSqlDialect which is already doing this. > Changes in other Dialects can follow suit. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
