[ 
https://issues.apache.org/jira/browse/CALCITE-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16727791#comment-16727791
 ] 

Marc Prud'hommeaux commented on CALCITE-2752:
---------------------------------------------

I think it is the RelJsonWriter that is at fault, since the JSON for the SQL 
"SELECT * FROM (VALUES(1.1)) T WHERE 2.22 < 3.3" is:

 
{code:json}
{
  "rels": [
    {
      "id": "0",
      "relOp": "LogicalValues",
      "type": [
        {
          "type": "DECIMAL",
          "nullable": false,
          "precision": 2,
          "scale": 1,
          "name": "EXPR$0"
        }
      ],
      "tuples": [
        [
          11
        ]
      ],
      "inputs": []
    },
    {
      "id": "1",
      "relOp": "LogicalFilter",
      "condition": {
        "op": "<",
        "operands": [
          222,
          33
        ]
      }
    },
    {
      "id": "2",
      "relOp": "LogicalProject",
      "fields": [
        "EXPR$0"
      ],
      "exprs": [
        {
          "input": 0,
          "name": "$0"
        }
      ]
    }
  ]
}
{code}
 

The serialized operands for the query (222 instead of 2.22, and 33 instead of 
3.3) aren't even annotated with a "precision" and "scale", so they couldn't 
possibly be reconstructed from the JSON representation.

 

> 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
>            Priority: Major
>
> 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)

Reply via email to