+1 (non-binding) On Tue, Oct 13, 2026 at 9:51 PM Daniel Weeks <[email protected]> wrote:
> +1 (binding) > > On Tue, Oct 13, 2026 at 8:48 AM Anurag Mantripragada < > [email protected]> wrote: > >> +1 (non-binding) >> >> ~ Anurag >> >> On Tue, Oct 13, 2026 at 8:08 AM Alex Stephen via dev < >> [email protected]> wrote: >> >>> +1 (non-binding) >>> >>> Excited to see this move forward! Thanks for the hard work everyone! >>> On Tue, Oct 13, 2026 at 7:42 AM Anoop Johnson <[email protected]> wrote: >>> >>>> +1 (non-binding) >>>> >>>> On Tue, Oct 13, 2026, 7:33 AM Péter Váry <[email protected]> >>>> wrote: >>>> >>>>> +1 >>>>> >>>>> Steven Wu <[email protected]> ezt írta (időpont: 2026. okt. 13., >>>>> K, 16:31): >>>>> >>>>>> +1 (binding) >>>>>> >>>>>> On Tue, Oct 13, 2026 at 6:23 AM Alex Dutra <[email protected]> wrote: >>>>>> >>>>>>> +1 (non-binding) >>>>>>> >>>>>>> On Tue, Oct 13, 2026 at 2:13 PM 전대홍 <[email protected]> wrote: >>>>>>> > >>>>>>> > +1 (non-binding) >>>>>>> > >>>>>>> > Happy to help bring the file type to iceberg-rust once this lands. >>>>>>> > >>>>>>> > 2026년 10월 13일 (화) 오후 9:09, Manu Zhang <[email protected]>님이 >>>>>>> 작성: >>>>>>> >> >>>>>>> >> +1 (non-binding) >>>>>>> >> >>>>>>> >> Neelesh Salian <[email protected]>于2026年10月13日 周二18:30写道： >>>>>>> >>> >>>>>>> >>> +1 (non-binding) >>>>>>> >>> >>>>>>> >>> On Tue, Oct 13, 2026 at 08:51 Talat Uyarer via dev < >>>>>>> [email protected]> wrote: >>>>>>> >>>> >>>>>>> >>>> Hi everyone, >>>>>>> >>>> >>>>>>> >>>> I'd like to start a vote on adding the file data type to the v4 >>>>>>> table spec, as proposed in this PR: >>>>>>> >>>> >>>>>>> >>>> https://github.com/apache/iceberg/pull/17918 >>>>>>> >>>> >>>>>>> >>>> The spec change does the following: >>>>>>> >>>> >>>>>>> >>>> New file type: a range of bytes stored either inline or as a >>>>>>> reference to an external file. Its value semantics follow the FILE >>>>>>> logical >>>>>>> type in the Parquet spec. >>>>>>> >>>> >>>>>>> >>>> Fixed, implicit sub-fields: uri, offset, size, content_type, >>>>>>> checksum and inline. They don't appear in the schema and can't be added, >>>>>>> removed, reordered or promoted. Their field IDs are offsets +1 to +6 >>>>>>> from >>>>>>> the file field's ID, so adding a file field moves last-column-id >>>>>>> forward by >>>>>>> 7. >>>>>>> >>>> >>>>>>> >>>> URIs: a uri can be absolute or relative. Relative URIs resolve >>>>>>> against the table location. >>>>>>> >>>> >>>>>>> >>>> Stats: each sub-field gets its own field stats. Writers should >>>>>>> produce stats for uri, content_type and inline. >>>>>>> >>>> >>>>>>> >>>> Restrictions: >>>>>>> >>>> - Equality, ordering and hashing aren't defined for file values. >>>>>>> >>>> - A file column can't be an identifier field or a source for >>>>>>> partition or sort transforms. >>>>>>> >>>> - A file column must default to null. >>>>>>> >>>> - A file isn't interchangeable with a struct that has the same >>>>>>> sub-fields, and can't be promoted from one. >>>>>>> >>>> - A uri doesn't guarantee the referenced file exists. >>>>>>> >>>> >>>>>>> >>>> Format mappings: >>>>>>> >>>> - Parquet: map with the FILE logical type. >>>>>>> >>>> - Avro: record. >>>>>>> >>>> - ORC: struct with iceberg.struct-type=FILE. >>>>>>> >>>> >>>>>>> >>>> JSON schema serialization: "file". >>>>>>> >>>> >>>>>>> >>>> FILE type is v4 only. Writing file into a v3 or earlier schema >>>>>>> is invalid. >>>>>>> >>>> >>>>>>> >>>> Please vote in the next 72 hours. >>>>>>> >>>> >>>>>>> >>>> [ ] +1 Add the File type to the v4 spec >>>>>>> >>>> [ ] +0 >>>>>>> >>>> [ ] -1 I have concerns because... >>>>>>> >>>> >>>>>>> >>>> Thanks, >>>>>>> >>>> Talat on behalf of FILE type working group >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>>>>
