[
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)