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

Reply via email to