+1 (non-binding) On Mon, Oct 19, 2026 at 10:49 AM Yufei Gu <[email protected]> wrote:
> +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 >>>>>>> > >> >>>>>>> > > >>>>>>> > >>>>>>> >>>>>>
