rdblue commented on PR #5230: URL: https://github.com/apache/iceberg/pull/5230#issuecomment-1194554908
I'm not sure about this. At first, it seems like a reasonable thing to support. But, Iceberg table properties are not intended to be used for arbitrary user metadata like this. They are intended for information to configure reading or writing a table. The existing behavior is that set is idempotent, so it is a stretch to say that Iceberg should support a new feature so you can use table properties for a different purpose. There is also an implementation problem with this. Not all catalogs can guarantee the behavior introduced in this PR. For example, the REST protocol's `SetPropertiesUpdate` is an idempotent change. There's no way to communicate what the catalog service should do if there is a conflict, or even to signal that it should fail and retry in the event of a conflict. At a minimum, we would need to add a validation for table properties that enabled failing the server-side commit. I'm not sure that those changes are worth it. Have you considered using a prefix instead of a single option? Instead of `subscribers=a,b,c` you could set `subscribers.a.enabled=true`, `subscribers.b.enabled=true`, etc. That gives you the ability to customize each one as well. -- 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]
