You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by "Marc Prud'hommeaux (JIRA)" <ji...@apache.org> on 2018/12/23 02:40:00 UTC

[jira] [Created] (CALCITE-2752) Round-tripping RelNode via RelJson corrupts decimal literals

Marc Prud'hommeaux created CALCITE-2752:
-------------------------------------------

             Summary: Round-tripping RelNode via RelJson corrupts decimal literals
                 Key: CALCITE-2752
                 URL: https://issues.apache.org/jira/browse/CALCITE-2752
             Project: Calcite
          Issue Type: Bug
    Affects Versions: 1.17.0
            Reporter: Marc Prud'hommeaux
            Assignee: Julian Hyde


The SQL statement "VALUES 1.23" when parsed and converted into a RelNode is explained as "1:LogicalValues(tuples=[[\{ 1.23 }]])". So far so good.

 

Then writing it out with a RelJsonWriter yields:

 
{code:java}
{
"rels": [
{
"id": "0",
"relOp": "LogicalValues",
"type": [
{
"type": "DECIMAL",
"nullable": false,
"precision": 3,
"scale": 2,
"name": "EXPR$0"
}
],
"tuples": [
[
123
]
],
"inputs": []
}
]
}
{code}
  

When it is read back in with a RelJsonReader, the new RelNode is explained as "2:LogicalValues(tuples=[[\{ 123 }]])" and the re-built SQL from RelToSqlConverter is: SELECT * FROM (VALUES (123)) AS "t" ("EXPR$0").

 

I can't quite tell if the fault lies with the RelJsonWriter (for writing out "123") or the RelJsonReader (for not re-building the decimal using the "precision" and "scale" arguments).

 

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)