+1 binding On Tue, Oct 13, 2026 at 12:50 AM 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 > > > >
