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 >
