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