szlta commented on code in PR #17155:
URL: https://github.com/apache/iceberg/pull/17155#discussion_r3672476750
##########
docs/docs/catalog-properties.md:
##########
@@ -55,6 +56,7 @@ The following properties configure the behavior of the REST
catalog client.
| `rest-page-size` | null | The page size to
use when listing namespaces, tables, or other paginated resources.
|
| `namespace-separator` | `%1F` | The separator
character used for namespace levels when communicating with the REST server.
|
| `scan-planning-mode` | `CLIENT` | Controls where
scan planning is performed. Supported values: `CLIENT` (client-side planning),
`SERVER` (server-side planning). Can be overridden per-table by the server in
LoadTableResponse. |
+| `encryption.kms-type` | null | KMS provider
type used for encrypted tables. Clients may configure this value, but REST
catalog servers may advertise it through `/v1/config`; server `overrides` take
precedence over client configuration. When using `key-management-credentials`,
clients should use the final catalog configuration value after applying server
defaults and overrides. The value is an open enum with initial values `aws`,
`gcp`, and `azure`; catalogs may return additional values when the catalog and
client agree on KMS client resolution and credential config. |
Review Comment:
Today in Iceberg there can only be one KMS type associated to a catalog, so
as also stated in the design doc, this is a catalog-level capability.
I'd rather catalog level traits / configs / capabilities to be announced in
the `/config` response than repeating them in every single `/loadTable`
response.
--
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]
