+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 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>
