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