1. Current semantics is that existing #getTable(ObjectPath tablePath) method imply read privilege only. It's ok for pass the select privilege if required. I can change the TableWritePrivilege to TablePrivilege, and then I add the privilege `SELECT` which indicates retrieve data from the data. I have modified the document about this part. 2. Ok for me if Flink community prefer this way. I have changed the `default interface method` to `interface method` in the document. 3. I added this section in the document. Actually, Is it clear enough? Actually, I have finished some work in the Apache Gravitino community. You can see https://github.com/apache/gravitino/pull/9947 and https://github.com/apache/gravitino/pull/9585. Hopes that they can help you understand my proposal better.
Leonard Xu <[email protected]> 于2026年2月10日周二 19:08写道： Leonard Xu <[email protected]> 于2026年2月10日周二 19:08写道： > > > 1. If we don't pass any write privilege, it means that we need a select > > privilege. > > This assumption is pretty implicit IMO. As for the existing > #getTable(ObjectPath tablePath) method, which doesn't pass any privilege > parameter, what is its current semantics? Does it imply read privilege > only? > > > > 2. If someone else have implemented his catalog store and custom catalog, > > he can use new version Flink without modification. If we don't provide > the > > fallback implementation, he need to implement the new method, and compile > > the new package > > When user decide to bump a higher flink version with API changes, it makes > sense they need to adjust their catalog implementation with higher flink > API. > > > Usually, access control is disabled by default. It should be enabled when > > access control is required. If someone require the access control, he > > should implement the new method. > > I think we need to clarify how user enable/disable the access control as > this the FLIP purpose, It’s not clear how user use current proposed API > now, could you add a section in your FLIP?
