[ 
https://issues.apache.org/jira/browse/CALCITE-2623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)

Reply via email to