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
>>>
>>
