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

Reply via email to