Hi Talat, +0 (non-binding)
I left a comment on the specification PR. I apologize for the tardiness of my review. I will leave the same comment here: "I still feel strongly that we need a field (I am not attached to a specific name) that indicates to maintenance operations that the files at the URI are safe to remove or otherwise manipulate." My concern is that without a specific well defined field for this information to be stored there is no way to have a media bucket that multiple tables can point to which then requires copying the data multiple times. I don't think the specification has to define how this safety indicator is updated or changed (if at all) that should be an implementation detail. If we can add a field that lets maintenance operations know that its safe to delete a file (for example) then I will amend my vote to plus one. Best Regards, Kurtis C. Wright On Wed, Oct 14, 2026 at 6:34 AM Sung Yun <[email protected]> wrote: > +1 (binding) > > On 2026/10/14 08:55:59 Gang Wu wrote: > > +1 (binding) > > > > On Wed, Oct 14, 2026 at 2:56 PM Gaurav Soni <[email protected]> > wrote: > > > > > +1 (non-binding) > > > > > > On Tue, Oct 13, 2026 at 11:37 PM John Zhuge <[email protected]> wrote: > > > > > >> +1 (non-binding) > > >> > > >> On Tue, Oct 13, 2026 at 1:49 PM huaxin gao <[email protected]> > > >> wrote: > > >> > > >>> +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 > > >>>>>>>>>> >>>> > > >>>>>>>>>> >>>> > > >>>>>>>>>> >>>> > > >>>>>>>>>> > > >>>>>>>>> > > >> > > >> -- > > >> John Zhuge > > >> > > > > > >
