+1 (non-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 >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>>
