That sounds good to me. The field will still have to remain for the _metadata file but we can make it explicit that it is never populated in the file footer.
On Tue, Dec 2, 2025 at 3:36 AM Andrew Lamb <[email protected]> wrote: > I for one think it is a good idea, thank you for bringing it up Micah > > I think the best rationale for depreciation, as you mention, is to bring > the spec into alignment with actual implementation practice. The more > unused features exist in Parquet, the harder it is to implement new readers > or determine compatibility. > > Andrew > > On Mon, Dec 1, 2025 at 3:09 PM Micah Kornfield <[email protected]> > wrote: > > > This has come up a few times in the sync and other forums. I wanted to > > start the conversation about deprecating file_path > > < > > > https://github.com/apache/parquet-format/blob/3ab52ff2e4e1cbe4c52a3e25c0512803e860c454/src/main/thrift/parquet.thrift#L962 > > > > > [1] in the parquet footer. > > > > Outside of the "_metadata" file index use-case I don't think this is used > > or implemented in any reader (effectively a poor man's table format). > > > > With the rise of file formats, it seems like a reasonable design choice > to > > push complexity of referencing columns across files to the table level > and > > keep parquet focused on single file storage (encodings, indexing, etc). > > > > Implementing this at a file level also can be challenging in the context > of > > knowing all credentials one might need to read from different objects on > > object storage? > > > > Thoughts/Objections? > > > > Thanks, > > Micah > > > > > > [1] > > > > > https://github.com/apache/parquet-format/blob/3ab52ff2e4e1cbe4c52a3e25c0512803e860c454/src/main/thrift/parquet.thrift#L962 > > >
