raminqaf commented on code in PR #29311:
URL: https://github.com/apache/flink/pull/29311#discussion_r4152639195
##########
docs/content/docs/sql/reference/data-types.md:
##########
@@ -1677,6 +1678,45 @@ CAST(o AS MAP<STRING, VARIANT>) -- values kept as
variants, the variant null in
CAST(o AS MAP<INT, STRING>) -- fails at validation, a MAP key must be a
character string
```
+A scalar value can also be cast to a `VARIANT` with `CAST` or `TRY_CAST`. Only
a type that a
+`VARIANT` kind holds without loss is supported, and any other type, such as
`INTERVAL`, `RAW`, or
+`BITMAP`, is rejected at validation. The value keeps the kind of its SQL type:
+
+| Input type | Stored `VARIANT` kind
|
+|--------------------------------------------|-------------------------------------------------|
+| `BOOLEAN` | `BOOLEAN`
|
+| `TINYINT`, `SMALLINT`, `INTEGER`, `BIGINT` | `TINYINT`, `SMALLINT`, `INT`,
`BIGINT` |
+| `FLOAT`, `DOUBLE`, `DECIMAL` | `FLOAT`, `DOUBLE`, `DECIMAL`
|
+| `CHAR`, `VARCHAR`, `STRING` | `STRING`
|
+| `BINARY`, `VARBINARY`, `BYTES` | `BYTES`
|
+| `DATE`, `TIME`, `UUID` | `DATE`, `TIME`, `UUID`
|
+| `TIMESTAMP`, `TIMESTAMP_LTZ` | `TIMESTAMP`, `TIMESTAMP_LTZ`
|
+
+- An integer keeps the width of its SQL type, so a `BIGINT` is stored as a
`BIGINT` even when the
+ value would fit a smaller kind. `PARSE_JSON('1')` instead picks the smallest
kind, a `TINYINT`.
+ Either way it casts back to any integer type that holds the value.
+- A character string is stored as a `STRING` and is never parsed. Use
`PARSE_JSON` to parse JSON text.
+- A `TIMESTAMP(p)` or `TIMESTAMP_LTZ(p)` keeps its declared precision. Up to a
precision of 6 it is
Review Comment:
Yes, it's a conscious trade-off. Keeping the declared precision matches how
Flink treats `TIMESTAMP(p)` elsewhere: `CAST(TIMESTAMP(9) AS STRING)` always
prints nine digits, and the Avro format picks the unit from `p`.
Starting strict keeps the door open, since a fallback to micros would only
turn failing casts into working ones, while the other way round would break
queries. For sentinel dates, the error message suggests casting to
`TIMESTAMP(6)` first.
I wanted to avoid any magical type changes during the cast. If a user asks
for an explicit cast type they should get it or it should fail. No implecite
type changes.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
