Thanks for your input. 1. I can create a FLIP for this discussion. 2. CDC only uses insert data to imitate delete and update data. It should use `insert` privilege from the catalog perspective. 3. The behavior depends on the security model. There are two security models, invoker and definer. If you use the definer security model, you will use the privileges of the view definer to access underlying tables. If you use an invoker security model, you will use your own privileges to access underlying tables. More information, https://www.postgresql.org/docs/current/sql-createview.html
Xuyang <[email protected]> 于2026年2月3日周二 15:02写道： > Hi, Rory. Thanks for sharing. I've took a look at your PR and have a few > questions: > > > 1. I believe this warrants a FLIP, as it enriches the (public) Catalog > interface. > 2. I noticed that in `convertSqlInsert`, the sink's privileges are set to > INSERT only. I'm a bit curious: in the context of an INSERT INTO ... > statement, when the sink processes CDC data, it not only inserts new rows > but may also update or delete existing rows. > 3. Moreover, aside from write privileges, I can think of an interesting > scenario regarding read privileges: the user of the current pipeline has > privileges on a persistent view in the catalog but lacks privileges on the > underlying tables of that view. I’m wondering how we should handle this > case — should we reject it outright, or leave it to the catalog to handle? > > > > > > -- > > Best！ > Xuyang > > > > At 2026-02-01 16:25:57, "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 getTablemethod 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 > > > > - > > > > JIRA Issue: https://issues.apache.org/jira/browse/FLINK-38848 > > - > > > > Pull Request: https://github.com/apache/flink/pull/27389 > > > >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 >
