Thanks for your reply. 1. I added code in the section `Public Interfaces`. Thanks for your guidance. 2. Actually other systems may implement a custom CatalogManager. So it would be better to keep compatible. 3. I got your point. After thinking, I feel I should change the description of the insert privilege. It should be ` The privilege of adding rows to the non-CDC table or writing data changes to the CDC table`. WDYT?
Xuyang <[email protected]> 于2026年2月10日周二 10:28写道： > > Thanks for driving this. Overall it looks good to me, and I have some minor > comments below: > 1. Please refer to other FLIPs and list the code changes to the public API in > the "Public Interfaces" section. > 2. CatalogManager is an internal API, and can we directly modify the existing > getTable method? > 3. For CDC write scenarios, setting TableWritePrivilege to INSERT feels a bit > odd IMO, especially given its description "/** The privilege of adding rows > to the table. */". Curious to hear others’ thoughts. > > > > > > -- > > Best！ > Xuyang > > > > At 2026-02-09 23:39:09, "roryqi" <[email protected]> wrote: > >Hi Flink Community, > > > >I'd like to propose an enhancement to the Catalog interface to better > >support access control scenarios. > > > >Problem Statement > > > >For custom catalogs that implement access control, read and write > >permissions often need to be distinguished. Currently, Flink always invokes > >Catalog#getTableto look up tables, regardless of whether the operation is > >for reading or writing. This limitation makes it challenging for catalogs > >to enforce proper write-level access control. > > > >Proposed Solution > > > >I've submitted a PR that adds a new variant of getTable method which > >explicitly indicates when write privileges are required. Key aspects of > >this implementation: > > > >Backward Compatibility: The new method includes a default implementation > >that calls the existing getTable, ensuring no breaking changes > > > >Write Operation Coverage: All write operations (INSERT, UPDATE, DELETE, > >etc.) will use this new method for table lookup > > > >Industry Validation: This approach aligns with Apache Spark's similar > >interface enhancement (see https://github.com/apache/spark/pull/47772) > > > >Reference Materials > > > >FLIP Link: > >https://docs.google.com/document/d/1wf7PGYURa8jH69ISU-xV7HNctaWViZw3t9sy-niuAbI/edit?tab=t.0 > > > >JIRA Issue: https://issues.apache.org/jira/browse/FLINK-38848 > > > >Pull Request: https://github.com/apache/flink/pull/27389 > > > >Previous discussion thread: > >https://lists.apache.org/thread/gfq316x9vrdwmgpw0hx4r7gpc0qkgvk1 > > > >This enhancement would significantly improve catalog implementations' > >ability to enforce fine-grained access control, particularly important in > >multi-tenant environments. I'm happy to start a discussion on the dev > >mailing list if that would be more appropriate for this type of interface > >change. > > > >Looking forward to the community's feedback on this discussion > > > >Best > > > >Rory
