zeroshade commented on code in PR #43234:
URL: https://github.com/apache/arrow/pull/43234#discussion_r1683355253
##########
docs/source/format/CanonicalExtensions.rst:
##########
@@ -283,6 +283,28 @@ UUID
A specific UUID version is not required or guaranteed. This extension
represents
UUIDs as FixedSizeBinary(16) with big-endian notation and does not
interpret the bytes in any way.
+8-bit Boolean
+====
+
+Bool8 represents a boolean value using 1 byte (8 bits) to store each value
instead of only 1 bit as in
+the native Arrow Boolean type. Although less compact that the native
representation, Bool8 may have
+better zero-copy compatibility with various systems that also store booleans
using 1 byte.
+
+* Extension name: ``arrow.bool8``.
+
+* The storage type of this extension is ``Int8`` where:
+
+ * **false** is denoted by the value ``0``.
+ * **true** can be specified using any non-zero value.
Review Comment:
> I'm saying to not use MUST/SHOULD language anymore because people do not
necessarily have RFC2119 in mind when they read specs, but my intent, in
non-RFC speak remains the same:
That's fair and makes a lot of sense. I thought there was more to the intent
of explicitly making it requirement for producers. Though I don't necessarily
like the wording of "non-strictly compliant" in this context, we can recommend
using `1` and say it is preferred (like we do in other areas such as offset
buffers starting with 0) but ultimately the point is that we're explicitly
allowing for it to not be in [0, 1] and therefore consumers can never assume it
is unless they *know* the producer did that.
> I thought this would be a non-controversial proposal:
Honestly, I'm fine with that change given that we say it's recommended or
that producers "should" produce [0, 1]. I don't think it's controversial at
all. @joellubi?
--
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]
