Thank you Timo and Ron. Updated FLIP the voting thread[1] [1] https://lists.apache.org/thread/x7k41wtmp15wrcg7dqpb1f8tw1wstk0s
On Wed, Nov 5, 2025 at 10:01 AM Timo Walther <[email protected]> wrote: > > Hi Ron, > > thanks for the clarification. I guess we are on the same page then. No > additional physical columns in DDL that are not in query, but refinement > of physical columns in query can be part of the DDL. > > @Sergey: Please update the FLIP. +1 for voting. > > Thanks, > Timo > > > On 04.11.25 02:26, Ron Liu wrote: > > Hi, Timo. > > > > I've always been in favor of declaring types and names in DDL for columns > > in a query. Only just disagree with adding physical columns in DDL that are > > not in the query. > > > > Best, > > Ron > > > > Timo Walther <[email protected]> 于2025年11月3日周一 22:03写道： > > > >> Hi Sergey, > >> > >> +1 for this FLIP. But one last comment: > >> > >> @Ron: I'm fine excluding adding/altering physical columns. But should we > >> still allow the case where the data type of column should be declared or > >> the column name or COMMENT? > >> > >> E.g. take: > >> > >> CREATE MATERIALIZED TABLE AS SELECT 'Hello'; > >> > >> By default it will result in (CHAR(5)). Shouldn't we allow users to define: > >> > >> > >> CREATE MATERIALIZED TABLE (name STRING) AS SELECT 'Hello'; > >> > >> We can forbid adding additional columns, but at least the one of the > >> query could be better defined. > >> > >> Also e.g.: > >> > >> CREATE MATERIALIZED TABLE (name STRING COMMENT 'Comment of the user') AS > >> SELECT 'Hello'; > >> > >> What do you think? > >> > >> Cheers, > >> Timo > >> > >> > >> > >> > >> > >> On 02.11.25 23:35, Sergey Nuyanzin wrote: > >>> Great, thank you Ron! > >>> > >>> In case there is no more feedback > >>> I would suggest to move to voting[1] step > >>> > >>> [1] https://lists.apache.org/thread/x7k41wtmp15wrcg7dqpb1f8tw1wstk0s > >>> > >>> On Thu, Oct 30, 2025 at 2:34 AM Ron Liu <[email protected]> wrote: > >>>> > >>>> Thanks for update, LGTM. > >>>> > >>>> Best, > >>>> Ron > >>>> > >>>> Sergey Nuyanzin <[email protected]> 于2025年10月30日周四 08:18写道： > >>>> > >>>>> Cool, thank you > >>>>> updated FLIP > >>>>> would be great if you have time to check it and tell if anything else > >>>>> should be changed > >>>>> > >>>>> On Wed, Oct 29, 2025 at 2:47 AM Ron Liu <[email protected]> wrote: > >>>>>> > >>>>>> Hi, Sergey > >>>>>> > >>>>>> Makes sense to me. > >>>>>> > >>>>>> Best, > >>>>>> Ron > >>>>>> > >>>>>> Sergey Nuyanzin <[email protected]> 于2025年10月29日周三 06:29写道： > >>>>>> > >>>>>>> Hi Ron, > >>>>>>> thank you for your reply > >>>>>>> > >>>>>>>>>> I agree with the case for a compute column or metadata column, but > >>>>> I > >>>>>>> still > >>>>>>> don't think physical columns should be added. I haven't seen a > >>>>> real-world > >>>>>>> case for it, so it shouldn't be supported with that syntax. > >>>>>>> > >>>>>>> As mentioned above, I'm ok to exclude physical columns from this FLIP > >>>>>>> and introduce a separate validation which will forbid them. > >>>>>>> > >>>>>>> If this sounds ok, then I will update FLIP's page about that > >>>>>>> > >>>>>>> On Tue, Oct 28, 2025 at 2:45 AM Ron Liu <[email protected]> wrote: > >>>>>>>> > >>>>>>>> Hi, Sergey > >>>>>>>> > >>>>>>>> Sorry for late reply. > >>>>>>>> > >>>>>>>>>>> About more realworld case: sometimes it is required to pass extra > >>>>>>>> information like e.g. headers with help of compute or metadata > >>>>>>>> columns. > >>>>>>>> > >>>>>>>> We can add extra validation telling that physical columns are not > >>>>>>>> allowed to be added/modified/dropped. > >>>>>>>> > >>>>>>>> However even with metadata/compute columns it will require rewriting > >>>>>>>> the query (which will be done as a part of the operation). > >>>>>>>> WDYT? > >>>>>>>> > >>>>>>>> I agree with the case for a compute column or metadata column, but I > >>>>>>> still > >>>>>>>> don't think physical columns should be added. I haven't seen a > >>>>> real-world > >>>>>>>> case for it, so it shouldn't be supported with that syntax. > >>>>>>>> > >>>>>>>> > >>>>>>>> Best, > >>>>>>>> Ron > >>>>>>>> > >>>>>>>> > >>>>>>>> Sergey Nuyanzin <[email protected]> 于2025年10月21日周二 17:19写道： > >>>>>>>> > >>>>>>>>> Hi Ron, > >>>>>>>>> sorry for the delay > >>>>>>>>> > >>>>>>>>> About more realworld case: sometimes it is required to pass extra > >>>>>>>>> information like e.g. headers with help of compute or metadata > >>>>>>>>> columns. > >>>>>>>>> > >>>>>>>>> We can add extra validation telling that physical columns are not > >>>>>>>>> allowed to be added/modified/dropped. > >>>>>>>>> > >>>>>>>>> However even with metadata/compute columns it will require > >>>>> rewriting > >>>>>>>>> the query (which will be done as a part of the operation). > >>>>>>>>> WDYT? > >>>>>>>>> > >>>>>>>>>> A new question: regarding the operation ALTER MATERIALIZED TABLE > >>>>>>> MyTable > >>>>>>>>>> ADD PARTITION (p1=1, p2='a') WITH ('k1'='v1'), what is its > >>>>> intended > >>>>>>>>>> semantics? Is it purely a metadata-only operation, or does it also > >>>>>>> trigger > >>>>>>>>>> a job to refresh data for the new partition? I believe it should > >>>>> be > >>>>>>> the > >>>>>>>>>> latter—what’s your view? > >>>>>>>>> > >>>>>>>>> yes it also should trigger job after that > >>>>>>>>> > >>>>>>>>> On Fri, Oct 10, 2025 at 4:39 AM Ron Liu <[email protected]> > >>>>> wrote: > >>>>>>>>>> > >>>>>>>>>> Hi, Sergey. > >>>>>>>>>> > >>>>>>>>>> Thanks for your quick response. > >>>>>>>>>> > >>>>>>>>>>>>> Probably one of the main use cases here is column name > >>>>>>> reservation > >>>>>>>>> for > >>>>>>>>>> the future. > >>>>>>>>>> > >>>>>>>>>> I haven’t seen a concrete real-world business use case for this > >>>>>>> feature. > >>>>>>>>> My > >>>>>>>>>> concern is: if the sole motivation is to align syntactically with > >>>>>>> CTAS > >>>>>>>>>> (Create Table As Select), what is its actual value and > >>>>> significance? > >>>>>>>>>> > >>>>>>>>>>>>> Isn't it the same in the case of tables and pipelines bound > >>>>> to > >>>>>>> them? > >>>>>>>>>> I was thinking that since there is MaterializedTableManager, then > >>>>>>>>>> based on coming TableChangeOperation > >>>>>>>>>> it could decide then how to process such change: for example full > >>>>>>>>>> recompute or something more sophisticated > >>>>>>>>>> > >>>>>>>>>> I believe this is not entirely equivalent to a regular table: > >>>>>>>>>> > >>>>>>>>>> - A materialized table consists of multiple components: table > >>>>>>>>> metadata, > >>>>>>>>>> pipeline, and data. The pipeline is an integral part of the > >>>>>>>>> materialized > >>>>>>>>>> table and is managed by it. We must ensure the stability and > >>>>>>>>> consistency of > >>>>>>>>>> all these components. > >>>>>>>>>> - Unlike regular tables, the schema and data of a materialized > >>>>>>> table > >>>>>>>>> are > >>>>>>>>>> derived from and continuously updated by its defining query. > >>>>>>>>> Therefore, > >>>>>>>>>> when adding, modifying, or dropping columns, the correct > >>>>> approach > >>>>>>>>> should be > >>>>>>>>>> to first update the query, and let the query drive the schema > >>>>>>> change. > >>>>>>>>>> This is logically sound and delivers real business value. This > >>>>>>>>> capability > >>>>>>>>>> is already supported in FLIP-492[1] and FLIP-546 and can be > >>>>>>> further > >>>>>>>>>> extended. > >>>>>>>>>> - Allowing column modifications via ALTER MATERIALIZED TABLE > >>>>>>>>>> ADD/MODIFY/DROP COLUMN would cause a mismatch between the > >>>>>>> materialized > >>>>>>>>>> table’s query definition and its physical schema, leading to > >>>>>>>>> inconsistency > >>>>>>>>>> and significantly increasing operational and observability > >>>>> costs. > >>>>>>>>> Maybe > >>>>>>>>>> also confuse the user. > >>>>>>>>>> - Due to the special nature of materialized tables, metadata > >>>>>>>>>> modifications must be handled with great caution. We should > >>>>> not > >>>>>>> allow > >>>>>>>>>> arbitrary schema changes—for example, we cannot freely reorder > >>>>>>>>> columns or > >>>>>>>>>> change column types, and we may not even allow arbitrary > >>>>> column > >>>>>>>>> deletions, > >>>>>>>>>> as these could break data compatibility. Moreover, if the > >>>>>>> underlying > >>>>>>>>>> physical storage doesn’t support such changes, the pipeline > >>>>> may > >>>>>>> fail > >>>>>>>>> to > >>>>>>>>>> run, and the MaterializedTableManager would be unable to > >>>>> handle > >>>>>>> it. In > >>>>>>>>>> such cases, the best solution is for the user to explicitly > >>>>>>> recreate > >>>>>>>>> the > >>>>>>>>>> materialized table. We must be cautious with user data—we > >>>>> should > >>>>>>> not > >>>>>>>>>> silently rebuild the physical table or reprocess historical > >>>>> data > >>>>>>> on > >>>>>>>>> the > >>>>>>>>>> user’s behalf. Additionally, from a technical perspective, we > >>>>> may > >>>>>>>>> currently > >>>>>>>>>> lack the capability to perform a full historical backfill in > >>>>>>>>>> MaterializedTableManager, so such operations should be > >>>>> explicitly > >>>>>>>>> triggered > >>>>>>>>>> by the user. > >>>>>>>>>> > >>>>>>>>>> A new question: regarding the operation ALTER MATERIALIZED TABLE > >>>>>>> MyTable > >>>>>>>>>> ADD PARTITION (p1=1, p2='a') WITH ('k1'='v1'), what is its > >>>>> intended > >>>>>>>>>> semantics? Is it purely a metadata-only operation, or does it > >>>>> also > >>>>>>>>> trigger > >>>>>>>>>> a job to refresh data for the new partition? I believe it should > >>>>> be > >>>>>>> the > >>>>>>>>>> latter—what’s your view? > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> With respect to the operations proposed in the FLIP, I think we > >>>>> can > >>>>>>>>> support > >>>>>>>>>> those that only affect metadata and do not impact the > >>>>> materialized > >>>>>>>>> table’s > >>>>>>>>>> query logic or data update behavior. The following operations are > >>>>>>>>>> acceptable: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> - Support defining watermarks when creating a MATERIALIZED > >>>>> TABLE. > >>>>>>>>>> - Support specifying a column_list when creating a > >>>>> MATERIALIZED > >>>>>>> TABLE. > >>>>>>>>>> - Support ALTER MATERIALIZED TABLE to add watermarks, primary > >>>>>>> keys, or > >>>>>>>>>> partitions. > >>>>>>>>>> - Support ALTER MATERIALIZED TABLE to drop watermarks, primary > >>>>>>> keys, > >>>>>>>>> or > >>>>>>>>>> partitions. > >>>>>>>>>> > >>>>>>>>>> For all other operations that would affect data updates or > >>>>> require > >>>>>>> query > >>>>>>>>>> rewriting, I remain cautious and reserved. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> 1. > >>>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>> > >> https://cwiki.apache.org/confluence/display/FLINK/FLIP-492%3A+Support+Query+Modifications+for+Materialized+Tables > >>>>>>>>>> > >>>>>>>>>> 2. > >>>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>> > >> https://cwiki.apache.org/confluence/display/FLINK/FLIP-546%3A+Introduce+CREATE+OR+ALTER+for+Materialized+Tables > >>>>>>>>>> > >>>>>>>>>> Best, > >>>>>>>>>> Ron > >>>>>>>>>> > >>>>>>>>>> Sergey Nuyanzin <[email protected]> 于2025年10月9日周四 18:38写道： > >>>>>>>>>> > >>>>>>>>>>> Hi Ron, > >>>>>>>>>>> > >>>>>>>>>>> thank you for the feedback > >>>>>>>>>>> > >>>>>>>>>>>> When adding new columns via CREATE or ALTER that are not > >>>>> included > >>>>>>> in > >>>>>>>>> the > >>>>>>>>>>> defining query of the Materialized Table—who is responsible for > >>>>>>>>> updating > >>>>>>>>>>> the data in these new columns? > >>>>>>>>>>> > >>>>>>>>>>> when we detect some new columns which are not present in query, > >>>>>>>>>>> then > >>>>>>>>>>> 1) validate that the type of each of them is nullable > >>>>> (otherwise > >>>>>>> throw > >>>>>>>>>>> ValidationException) > >>>>>>>>>>> 2) merge them into schema > >>>>>>>>>>> 3) rewrite materializedTable query in a way that now this query > >>>>>>> fills > >>>>>>>>>>> newly added columns with nulls. > >>>>>>>>>>> It means that newly rewritten query will be responsible for > >>>>> filling > >>>>>>>>>>> these null values > >>>>>>>>>>> The approach is similar to the way CTAS behaves in the same > >>>>>>> situation. > >>>>>>>>>>> > >>>>>>>>>>> Probably one of the main use cases here is column name > >>>>> reservation > >>>>>>> for > >>>>>>>>>>> the future. > >>>>>>>>>>> > >>>>>>>>>>>> For ALTER MATERIALIZED TABLE operations like ADD/MODIFY/DROP > >>>>>>>>>>> columns—these changes could cause the pipeline bound to the > >>>>>>>>> Materialized > >>>>>>>>>>> Table to fail. > >>>>>>>>>>> > >>>>>>>>>>> Isn't it the same in the case of tables and pipelines bound to > >>>>>>> them? > >>>>>>>>>>> I was thinking that since there is MaterializedTableManager, > >>>>> then > >>>>>>>>>>> based on coming TableChangeOperation > >>>>>>>>>>> it could decide then how to process such change: for example > >>>>> full > >>>>>>>>>>> recompute or something more sophisticated > >>>>>>>>>>> > >>>>>>>>>>> Looking forward for your comments > >>>>>>>>>>> > >>>>>>>>>>> On Thu, Oct 9, 2025 at 11:13 AM Ron Liu <[email protected]> > >>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> Hi, Sergey. > >>>>>>>>>>>> > >>>>>>>>>>>> I was on vacation recently, so sorry for joining this > >>>>> discussion > >>>>>>> so > >>>>>>>>> late. > >>>>>>>>>>>> > >>>>>>>>>>>> I’ve carefully reviewed the FLIP, and purely from the > >>>>>>> perspective of > >>>>>>>>>>>> aligning Materialized Table operations with those of a > >>>>> regular > >>>>>>>>> Table, I > >>>>>>>>>>>> support this proposal in principle. However, in my > >>>>> understanding, > >>>>>>>>>>>> Materialized Tables and regular Tables are fundamentally > >>>>>>> different. A > >>>>>>>>>>>> Materialized Table is bound to a specific pipeline that > >>>>> updates > >>>>>>> its > >>>>>>>>>>>> data—this pipeline is generated from the associated query. In > >>>>>>>>> contrast, a > >>>>>>>>>>>> regular Table isn’t tied to any pipeline; users manually > >>>>> write > >>>>>>>>> queries to > >>>>>>>>>>>> update its data. Performing an ALTER operation on a regular > >>>>> Table > >>>>>>>>> only > >>>>>>>>>>>> modifies metadata, whereas performing ALTER on a Materialized > >>>>>>> Table > >>>>>>>>>>> affects > >>>>>>>>>>>> not only metadata but also the underlying data update > >>>>> mechanism. > >>>>>>>>>>>> > >>>>>>>>>>>> Given this context, I have the following questions: > >>>>>>>>>>>> 1. When adding new columns via CREATE or ALTER that are not > >>>>>>> included > >>>>>>>>> in > >>>>>>>>>>> the > >>>>>>>>>>>> defining query of the Materialized Table—who is responsible > >>>>> for > >>>>>>>>> updating > >>>>>>>>>>>> the data in these new columns? I’m unclear about the purpose > >>>>> and > >>>>>>> use > >>>>>>>>> case > >>>>>>>>>>>> for adding such columns. Could you provide a concrete > >>>>> example? > >>>>>>>>>>>> 2. For ALTER MATERIALIZED TABLE operations like > >>>>> ADD/MODIFY/DROP > >>>>>>>>>>>> columns—these changes could cause the pipeline bound to the > >>>>>>>>> Materialized > >>>>>>>>>>>> Table to fail. What is the exact execution flow for these > >>>>>>> operations? > >>>>>>>>>>> Could > >>>>>>>>>>>> you elaborate on the runtime behavior for each type of > >>>>> operation? > >>>>>>>>> Since > >>>>>>>>>>>> these actions impact actual data updates—not just > >>>>> metadata—this > >>>>>>> is a > >>>>>>>>>>>> critical concern. > >>>>>>>>>>>> In summary, I believe we shouldn’t blindly apply all regular > >>>>>>> Table > >>>>>>>>>>>> operations directly to Materialized Tables. Instead, we > >>>>> should > >>>>>>>>>>> selectively > >>>>>>>>>>>> support a subset of operations based on real-world usage > >>>>>>> scenarios > >>>>>>>>> and > >>>>>>>>>>>> semantic correctness. What’s your take on this? Best, Ron > >>>>>>>>>>>> > >>>>>>>>>>>> Sergey Nuyanzin <[email protected]> 于2025年10月8日周三 08:05写道： > >>>>>>>>>>>> > >>>>>>>>>>>>> Hi Lincoln, > >>>>>>>>>>>>> > >>>>>>>>>>>>> Thank you for your feedback. > >>>>>>>>>>>>> > >>>>>>>>>>>>> I guess we already have similar behavior for CTAS, where we > >>>>>>> could > >>>>>>>>> put > >>>>>>>>>>>>> more columns than we have for query. > >>>>>>>>>>>>> In this case these extra columns should be filled with > >>>>> nulls, > >>>>>>> and > >>>>>>>>> the > >>>>>>>>>>>>> query should be rewritten accordingly [1]. > >>>>>>>>>>>>> This also means that extra columns should have nullable > >>>>> type > >>>>>>>>> (there is > >>>>>>>>>>>>> a dedicated validation for this). > >>>>>>>>>>>>> It means that for non query columns we have such default > >>>>>>> values and > >>>>>>>>>>>>> query is rewritten taking them into account > >>>>>>>>>>>>> > >>>>>>>>>>>>> Regarding adding columns with alter, or some other changes > >>>>> like > >>>>>>>>>>>>> adding/dropping columns, constraints, distribution > >>>>>>>>>>>>> if I understand correctly MaterializedTableManager looking > >>>>> at > >>>>>>> table > >>>>>>>>>>>>> change can decide whether it should recompute materialized > >>>>>>> table or > >>>>>>>>>>>>> not > >>>>>>>>>>>>> > >>>>>>>>>>>>> Would it make sense? > >>>>>>>>>>>>> > >>>>>>>>>>>>> [1] > >>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>> > >> https://github.com/apache/flink/blob/3478ddf08bce49e271f69b922a37ccada6f58688/flink-table/flink-table-planner/src/main/java/org/apache/flink/table/planner/operations/converters/table/SqlCreateTableAsConverter.java#L66-L74 > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Tue, Oct 7, 2025 at 4:14 AM Lincoln Lee < > >>>>>>> [email protected] > >>>>>>>>>> > >>>>>>>>>>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Thanks Sergey for driving this FLIP, it's a great > >>>>> addition to > >>>>>>>>>>>>> materialized > >>>>>>>>>>>>>> table! > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Since it coincided with China's National Day holiday and > >>>>>>>>> everyone is > >>>>>>>>>>>>> still > >>>>>>>>>>>>>> on > >>>>>>>>>>>>>> vacation, we couldn't reply promptly. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I haven't fully reviewed all the content in the FLIP > >>>>> yet, but > >>>>>>>>>>> there's an > >>>>>>>>>>>>>> important issue on the ALTER statement: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Unlike a regular CREATE TABLE, Materialized Table > >>>>> derives its > >>>>>>>>> schema > >>>>>>>>>>> from > >>>>>>>>>>>>>> the defined query, columns are generated based on the > >>>>> query > >>>>>>> (and, > >>>>>>>>>>> similar > >>>>>>>>>>>>>> to a > >>>>>>>>>>>>>> materialized view, the underlying data for these columns > >>>>> is > >>>>>>>>> tightly > >>>>>>>>>>>>> coupled > >>>>>>>>>>>>>> to > >>>>>>>>>>>>>> the query definition). Therefore, we cannot simply > >>>>> interpret > >>>>>>> the > >>>>>>>>>>> effect > >>>>>>>>>>>>> of > >>>>>>>>>>>>>> an > >>>>>>>>>>>>>> single `ALTER MATERIALIZED TABLE ADD New_Column` > >>>>> statement. > >>>>>>>>>>> Supporting > >>>>>>>>>>>>> this > >>>>>>>>>>>>>> likely requires accompanying column default value，and > >>>>> raises > >>>>>>>>>>>>> compatibility > >>>>>>>>>>>>>> concerns regarding historical data, that is a complex > >>>>> topic > >>>>>>> we > >>>>>>>>>>> previously > >>>>>>>>>>>>>> discussed offline during the design process of FLIP-492. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Also, once Ron is back in the office, he may give a more > >>>>>>> detailed > >>>>>>>>>>>>> comment. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Best, > >>>>>>>>>>>>>> Lincoln Lee > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Sergey Nuyanzin <[email protected]> 于2025年10月2日周四 > >>>>> 20:15写道： > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Thank you Ramin > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> In case there is no more feedback/objections > >>>>>>>>>>>>>>> I would start voting thread next week > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On Thu, Sep 25, 2025 at 10:43 AM Ramin Gharib < > >>>>>>>>>>> [email protected]> > >>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Hi Sergey, > >>>>>>>>>>>>>>>> Thanks for driving this! This sounds good to me! +1 > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Cheers, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Ramin > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On Wed, Sep 24, 2025 at 2:14 PM Sergey Nuyanzin < > >>>>>>>>>>> [email protected] > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Hi everyone, > >>>>>>>>>>>>>>>>> I'd like to start a discussion of FLIP-550 > >>>>>>>>>>>>>>>>> Add similar support for CREATE/ALTER operations for > >>>>>>>>>>> MATERIALIZED > >>>>>>>>>>>>>>>>> TABLEs as for TABLEs [1]. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> This FLIP is another step towards making tables and > >>>>>>>>>>> materialized > >>>>>>>>>>>>>>>>> tables more consistent. There was already one > >>>>>>> improvement > >>>>>>>>> in > >>>>>>>>>>> that > >>>>>>>>>>>>>>>>> direction like FLIP-542 [2] to add DISTRIBUTION and > >>>>>>> SHOW > >>>>>>>>>>>>> MATERIALIZED > >>>>>>>>>>>>>>>>> TABLES support. However there were several more > >>>>> things > >>>>>>>>> noticed > >>>>>>>>>>>>>>>>> comparing behavior for CREATE and ALTER > >>>>> operations. For > >>>>>>>>>>> instance > >>>>>>>>>>>>> right > >>>>>>>>>>>>>>>>> now for materialized tables it is impossible to set > >>>>>>>>> anything > >>>>>>>>>>> but > >>>>>>>>>>>>> table > >>>>>>>>>>>>>>>>> constraint while for tables (CREATE TABLE AS) it is > >>>>>>>>> possible to > >>>>>>>>>>>>>>>>> provide schema definition since FLIP-463 [3], also > >>>>>>> ALTER > >>>>>>>>>>> operations > >>>>>>>>>>>>>>>>> for TABLE is a way more mature than for > >>>>> MATERIALIZED > >>>>>>> TABLE. > >>>>>>>>>>> This > >>>>>>>>>>>>> FLIP > >>>>>>>>>>>>>>>>> is about to decrease the difference by enabling > >>>>> more > >>>>>>>>> similar > >>>>>>>>>>>>> features > >>>>>>>>>>>>>>>>> for materialized tables. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Introducing schema definition support for > >>>>> materialized > >>>>>>>>> tables > >>>>>>>>>>> will > >>>>>>>>>>>>>>>>> provide users with greater control and flexibility > >>>>> and > >>>>>>> also > >>>>>>>>>>> will > >>>>>>>>>>>>> unify > >>>>>>>>>>>>>>>>> usage of tables and materialized tables. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> [1] > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>> > >> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=387648095 > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> [2] > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>> > >> https://cwiki.apache.org/confluence/display/FLINK/FLIP-542%3A+Make+materialized+table+DDL+consistent+with+regular+tables > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> [3] > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>> > >> https://cwiki.apache.org/confluence/display/FLINK/FLIP-463%3A+Schema+Definition+in+CREATE+TABLE+AS+Statement > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> -- > >>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>> Sergey > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> -- > >>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>> Sergey > >>>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> -- > >>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>> Sergey > >>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> -- > >>>>>>>>>>> Best regards, > >>>>>>>>>>> Sergey > >>>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> Best regards, > >>>>>>>>> Sergey > >>>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> Best regards, > >>>>>>> Sergey > >>>>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Best regards, > >>>>> Sergey > >>>>> > >>> > >>> > >>> > >> > >> > > > -- Best regards, Sergey
