Re: File Type: URI Relativization Behavior

[kurtiscwright]

 Hi Russell, Thank you for summarizing and starting the thread. My initial thinking after listening to the discussion this morning, is that these references should be user defined and Iceberg should manage the references themselves only not the data they point to. For point 1. I think the references should be treated, at least initially, as absolute in terms of how Iceberg treats them. If a user wants to pass relative or something like that “s3://bucket/some-prefix-*” it’s their data. The spec should be written where there’s no expectation of expanding that URI to an actual object or objects path. For point 2. I think Iceberg should return the URIs exactly the same as they were written. It opens Iceberg to potential correctness bugs if there was resolution being done at Read time. For point 3. I am in favor of the model that Iceberg owns the column’s data, but not where the reference points. So for example if the URI pointed at an image, maintenance can run on the URI just never the image. Off the top of my head this allows duplicate URIs, objects in different buckets or even providers and it affords Iceberg the full suite of Maintenance activities without special handling.  Otherwise if Iceberg owned the object being pointed to, then we’ll have to define different types of objects the FILE type can point to and how to handle each. Which at a future date we may want, but I’m initially hesitant to agree with because it increases the scope of the feature vs just owning the URIs and metadata as defined in Parquet. 4. I’m currently in favor of pushing this to a later iteration and just have a single mode of ownership that I tried to describe above. Best Regards, Kurtis On Sep 2, 2026, at 12:11, Russell Spitzer <russell.spit...@gmail.com> wrote:  Hi y'all! Obviously we just had a long discussion on the behavior of a URI within an Iceberg's File Type and I wanted to make sure we continue the discussion and try to continue making progress before we have another follow up meeting. The TLDR for those who weren't attending: we are debating the File Type Proposal and the corresponding spec PR The key issue we want to continue discussing UDI subfield of the File type.  In parquet this field can be persisted as either a relative or absolute URI. Some community members are worried about having both representations which led to today's discussion. I want to open up the floor here for folks who have opinions on the behavior here. So the major questions (and my responses) are: 1. Can a URI be relative in an Iceberg Table? My response to this is yes. I don't think we gain much by forbidding it, and implementation wise I don't think we can reasonably stop it. Users can apply a constraint if they need this to be true. 2. On read, should Iceberg mandate converting that persisted relative value to an absolute URI, or should it represent the value exactly as read? I think every reader should return the value as is. I can't stop an engine from showing the user a different representation, but the bytes should be carried through as is in the file imho.  3. How should maintenance operations operate by default when a file column is present? By default, if we lack a mechanism for indicating ownership, we should assume all path references are not owned by the table. 4. Should the Spec or the implementation notes specify how tables should express ownership of the files they reference? I think this is probably something useful that we should lay out, but I don't think it needs to be decided for this proposal.  Please follow on if you have any other questions for debate or comments on these topics.