+1 (non-binding) Best, Burak
On Wed, Oct 14, 2026 at 8:07 PM Kurtis Wright <[email protected]> wrote: > 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 >> > >> >> > > >> > >> >
