gh-yzou commented on code in PR #4043:
URL: https://github.com/apache/polaris/pull/4043#discussion_r2986353336
##########
spec/polaris-catalog-apis/generic-tables-api.yaml:
##########
@@ -182,6 +186,26 @@ components:
type: string
example: "sales"
+ generic-table-data-access:
+ name: X-Generic-Table-Access-Delegation
+ in: header
+ description: >
+ Optional signal to the server that the client supports delegated access
+ via a comma-separated list of access mechanisms. The server may choose
+ to supply access via any or none of the requested mechanisms.
+
+
+ When `vended-credentials` is included, the server may return scoped
+ storage credentials in the `storage-access-configs` field of the
response.
+ required: false
+ schema:
+ type: string
+ enum:
Review Comment:
Yes, enum can only be one of them, the iceberg spec description is not
accurate, i updated the description to be more accurate.
##########
spec/polaris-catalog-apis/generic-tables-api.yaml:
##########
@@ -182,6 +186,26 @@ components:
type: string
example: "sales"
+ generic-table-data-access:
+ name: X-Generic-Table-Access-Delegation
+ in: header
+ description: >
+ Optional signal to the server that the client supports delegated access
+ via a comma-separated list of access mechanisms. The server may choose
+ to supply access via any or none of the requested mechanisms.
Review Comment:
i think we should be consistent on this across polaris, i updated the
description to be more clear
##########
spec/polaris-catalog-apis/generic-tables-api.yaml:
##########
@@ -182,6 +186,26 @@ components:
type: string
example: "sales"
+ generic-table-data-access:
+ name: X-Generic-Table-Access-Delegation
Review Comment:
I think the direction of the “generic table” concept is still evolving, and
it has the potential to expand beyond structured data to also cover
unstructured data.
From my perspective, the naming carries important implications. If we call
it generic-table-access-delegation, it suggests that the header is scoped
specifically to generic table APIs and applies only to entities managed within
that context. On the other hand, polaris-access-delegation implies a broader,
cross-cutting concept within Polaris that could be reused by future APIs. As
Yufei mentioned, this could also extend to use cases like Iceberg tables.
Since the overall direction is still not fully defined, I’m fine with either
name for now. However, I want to make sure we’re aligned on the underlying
concept and intended scope before finalizing it.
--
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]
