rdblue commented on code in PR #15630: URL: https://github.com/apache/iceberg/pull/15630#discussion_r3262210478
########## format/spec.md: ########## @@ -168,6 +185,46 @@ All columns must be written to data files even if they introduce redundancy with Writers are not allowed to commit files with a partition spec that contains a field with an unknown transform. +### Paths in Metadata + +Path strings stored in Iceberg metadata location fields are classified as one of two types: + +* **Absolute path** -- A path string that includes a [URI scheme](https://datatracker.ietf.org/doc/html/rfc3986#section-3.1) (e.g., `s3:`, `gs:`, `hdfs:`, `file:`). Absolute paths are used as-is without modification. +* **Relative path** -- A path string that does not include a URI scheme. Relative paths must be resolved against the table's base location before use. + +Prior to v4, all path fields must contain fully-qualified paths. Starting with v4, path fields may contain either absolute or relative paths. [Relative resolution within a URI](https://datatracker.ietf.org/doc/html/rfc3986#section-5.2) (e.g. `.` and `..`) and other file system navigation conventions are not supported in relative paths. Review Comment: Yeah, I guess you're right. I thought sure it was changed. I don't like saying that these aren't supported in relative paths, specifically. If you want to leave the possibility open in v3 and earlier, we can do that. But I think we should not leave open the possibility that absolute paths can contain directory navigation or other resolution patterns. I would just say that absolute and relative paths do not support these things. How about a separate paragraph: > [Relative resolution within a URI](https://datatracker.ietf.org/doc/html/rfc3986#section-5.2) (e.g. `.` and `..`) and other file system navigation conventions are not supported in absolute or relative paths. That way it is clear you can't use these conventions in either one. And making it a separate paragraph avoids implying that they are okay for v3 paths. We didn't specify they are not allowed, but we also chose not to implement any interpretation when issues came up, like whether `//` should be normalized or `./` should be removed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
