+1 (non-binding) вт, 13 окт. 2026 г., 09:15 Jean-Baptiste Onofré <[email protected]>:
> +1 (non binding) > > Regards > JB > > 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 >> >> >> >>
