+1 binding Yufei
On Mon, Oct 19, 2026 at 8:56 AM Orest Tokovenko <[email protected]> wrote: > +1 (non-binding). Happy to help bring the file type to pyiceberg once this > merges > > On Mon, Oct 19, 2026 at 8:08 AM Amogh Jahagirdar <[email protected]> wrote: > >> +1 (binding) >> >> On Mon, Oct 19, 2026 at 3:48 AM Dejan Krakovic via dev < >> [email protected]> wrote: >> >>> +1 (non-binding) >>> >>> Thanks, >>> Dejan >>> >>> On Mon, Oct 19, 2026 at 1:33 AM Burak Yavuz <[email protected]> wrote: >>> >>>> +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 >>>>>> > >> >>>>>> > > >>>>>> > >>>>>> >>>>>
