Le 10/09/2026 à 00:38, Ryan Blue a écrit :
There are 3 main options: 1. A reader should fail because it does not support the version 2. A reader should attempt to read the file 3. This choice is left up to implementations I'll cover each option in more detail below, but first I want to clarify that we are not talking about "preview" features like encodings or forward-compatible changes like new logical types. Preview features will break readers that do not support them and only affect specific columns using the feature. For preview features, the expectation is that readers will attempt to read the file and will fail if they need to project a column that cannot be read.
"Preview features" is a very weird terminology. It sounds like "unfinished" or "experimental".
The choice of how to handle an unsupported format version primarily affects changes that add, remove, or modify the semantics of metadata fields. For example: - Changing `path_in_schema` from required to optional
This depends whether the Thrift parser checks that required fields are actually present in the serialized payload? Do we know what their current behavior is?
i.e., does a Thrift parser generated with a required `path_in_schema` specification accept a serialized payload without that field?
It also depends what the Parquet reader actually *does* with the `path_in_schema`? AFAICT, the Parquet C++ reader isn't doing anything specific with it.
Option 3 would mean that readers may choose to attempt to read, but do not have additional guarantees.
Option 3 can also mean "the reader is exposing an option to let the user choose the behavior (reject up front or attempt to read anyway)".
(this would be more costly to implement, so I'm not sure any implementation would actually do that; but it's at least conceptually possible)
Regards Antoine.
