I think it would be good to revisit that discussion. This is somewhat orthogonal -- i.e. having a fixed-width binary type that does not have an accompanying list of n + 1 offsets.
On Tue, Jul 12, 2016 at 5:36 PM, Jacques Nadeau <jacq...@apache.org> wrote: > I was further reflecting on the previous discussion on lists and > binary/utf8. I think that treating strings (binary or utf8) as lists is too > much of reduction. This seems like a good example of how they are treated > differently (beyond the previously discussed not-possible-nullability). As > such I'm -1 on this change and would prefer if we go back and further > review the concept of treating a string of bits, or bytes as a "primitive" > type. > > On Tue, Jul 12, 2016 at 5:19 PM, Wes McKinney <wesmck...@gmail.com> wrote: > >> I'm +1 on this. I've seen fixed-width strings and other things in many >> different contexts. I would say that fixed-width binary is probably >> the primary use case, but you could imaging casting int96 data to >> fixed_list<3, int32> >> >> On Mon, Jul 11, 2016 at 11:24 PM, Micah Kornfield <emkornfi...@gmail.com> >> wrote: >> > This came up in a code review a while ago, but what do people think of >> > adding a fixed width list type to the memory layout spec. >> > >> > This would have the same layout as the current list type. Instead of >> > having a separate offset buffer to determine location and length of >> > each list, the length would be stored as part of metadata and offsets >> > would be calculated using multiplication instead of lookups. >> > >> > One use case for this is an easy mapping to the "FIXED_LEN_BYTE_ARRAY" >> > in parquet. >> > >> > If people like the idea I can file a JIRA and update the current >> layout.md. >> > >> > Thanks, >> > -Micah >>
