liukun4515 commented on code in PR #2471:
URL: https://github.com/apache/arrow-rs/pull/2471#discussion_r948009197
##########
parquet/src/data_type.rs:
##########
@@ -36,29 +36,27 @@ use crate::util::{
/// Rust representation for logical type INT96, value is backed by an array of
`u32`.
/// The type only takes 12 bytes, without extra padding.
-#[derive(Clone, Debug, PartialOrd, Default)]
+#[derive(Clone, Debug, PartialOrd, Default, PartialEq, Eq)]
Review Comment:
>
https://github.com/apache/arrow-rs/blob/master/parquet/src/column/writer/mod.rs#L1036
doesn't appear to special case this type
Do you think the logic of `compare_greater_byte_array_decimals` is wrong?
From the current implementation and test, it use the signed comparator with
little endian byte order.
so this crate is currently performing unsigned little endian comparison. I
don't think this is correct
##########
parquet/src/data_type.rs:
##########
@@ -36,29 +36,27 @@ use crate::util::{
/// Rust representation for logical type INT96, value is backed by an array of
`u32`.
/// The type only takes 12 bytes, without extra padding.
-#[derive(Clone, Debug, PartialOrd, Default)]
+#[derive(Clone, Debug, PartialOrd, Default, PartialEq, Eq)]
Review Comment:
>
https://github.com/apache/arrow-rs/blob/master/parquet/src/column/writer/mod.rs#L1036
doesn't appear to special case this type
Do you think the logic of `compare_greater_byte_array_decimals` is wrong?
From the current implementation and test, it use the signed comparator with
little endian byte order.
--
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]
