Thanks for your help. I have created a Google doc https://docs.google.com/document/d/1wf7PGYURa8jH69ISU-xV7HNctaWViZw3t9sy-niuAbI/edit?tab=t.0
Xuyang <[email protected]> 于2026年2月5日周四 15:27写道： > You can simply share your FLIP with Google Doc directly in the email. For > details, please refer to: > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=65145551#FlinkImprovementProposals-CreateyourOwnFLIP > > > > -- > > Best！ > Xuyang > > > > 在 2026-02-04 10:17:09，"roryqi" <[email protected]> 写道： > >Could anyone give me permission to create a FLIP in the wiki > >https://cwiki.apache.org/confluence/display/FLINK/Apache+Flink+Home? I > >found I don't have the permission. > > > > > >roryqi <[email protected]> 于2026年2月3日周二 16:03写道： > > > >> 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 > >>> > >> >
