Thanks Shengkai for the proposal! This should be very useful!
> In some cases, users might need to modify the nested column. Our proposal is > able to express the idea by introducing a new class named. My concern is that the connector needs to be implemented multiple times. Can we define classes at once so that the connector can be fully implemented, but we will not pass changes of the nested column. In addition, can we define the modified class of the nested column as the parent class? The top-level column modification is just a special case of a subclass. > ModifyColumn & RenameColumn ModifyColumn seems to be able to do RenameColumn's things? I prefer not to have classes such as ModifyColumn, and directly throw the most fine-grained changes to the Catalog to avoid any unsatisfied requirements in the future. Like ModifyColumnType ModifyColumnComment.... Can we add the corresponding SQL in the method comments? Best, Jingsong On Fri, Nov 18, 2022 at 11:55 AM Shengkai Fang <fskm...@gmail.com> wrote: > > Hi, dev. > > > I want to start a discussion about the FLIP-273: Improve Catalog API to > Support ALTER TABLE syntax[1]. The motivation of the FLIP is the current > Catalog API is difficult for some Catalog to alter the table. For example, > the Catalog only exposes > > void alterTable(ObjectPath tablePath, CatalogBaseTable newTable, boolean > ignoreIfNotExists) > > now. The main problem of this API is it requires the Catalog, > e.g.`JDBCCatalog` to compare the difference between the new > `CatalogTable`and the original CatalogTable, then generate the SQL to alter > the table in the external system. However, the `ALTER TABLE` syntax already > told the Catalog the differences. With the proposal, the Catalog developer > can easily support the `ALTER TABLE` syntax. > > Looking forward to feedback on that proposal. > > Best, > Shengkai > > > [1] > https://cwiki.apache.org/confluence/display/FLINK/FLIP-273%3A+Improve+the+Catalog+API+to+Support+ALTER+TABLE+syntax
