It's a good idea. There is no physical type corresponding to int48, using int48 will need extra decoding step to access the type and offset values. As it would change to use int8 type for the union type, this alternative proposal would also be invalidated and removed.
Regards, Kai -----Original Message----- From: Micah Kornfield [mailto:emkornfi...@gmail.com] Sent: Sunday, April 10, 2016 6:23 AM To: dev@arrow.apache.org Subject: Removng alternate proposal from layout of types and offsets for unions in layout.md The current layout.md lists an alternate proposal for the layout of of these values: "Alternate proposal (TBD): the types and offset values may be packed into an int48 with 2 bytes for the type and 4 bytes for the offset." Any objections to removing this proposal and moving forward with keeping them as two separate arrays? Thanks, Micah