scovich commented on code in PR #10015:
URL: https://github.com/apache/arrow-rs/pull/10015#discussion_r3357367724
##########
parquet-variant-compute/src/variant_array.rs:
##########
@@ -868,6 +868,20 @@ impl TryFrom<&StructArray> for ShreddingState {
}
}
+/// Build the `typed_value` [`FieldRef`] for a shredded column.
+///
+/// The Variant spec maps `FixedSizeBinary(16)` exclusively to UUID, so any
Review Comment:
I agree with that assessment. AFAIK, the arrow-parquet reader _never_
produces FLBA when reading decimal columns, regardless of how they were encoded
in the actual parquet? In particular,
[Decimal128Array](https://docs.rs/arrow/latest/arrow/array/type.Decimal128Array.html)
is a primitive array backed by
[Decimal128Type](https://docs.rs/arrow/latest/arrow/datatypes/struct.Decimal128Type.html),
which is physically backed by `i128`.
So when reading shredded variant data from parquet, any physical FLBA(16)
column we encounter must have either DECIMAL or UUID logical type (anything
else is an error). And when writing shredded variant to parquet, we would
either see a `FixedSizeBinaryArray(16)` with UUID extension type (any other
length or [lack of] extension type is an error), or `Decimal128Array`.
--
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]
