avamingli commented on PR #725: URL: https://github.com/apache/cloudberry/pull/725#issuecomment-2490785882
> This all comes from fact that dynamic table relkind is 'm' (mat. view). I'm not entirely sure if this design is good. Although the implementation is undoubtedly simpler in this manner, it is at least perplexing that changing a dynamic table requires M.V. SQL syntax. Another case here: > > ``` > reshke=# drop dynamic table tdd; > DROP DYNAMIC TABLE > reshke=# drop materialized view tdd ; > DROP MATERIALIZED VIEW > ``` > > Both succeeds. Yes, it's a materialized view actually. > Dynamic Table is a an auto-refreshing materialized view Dynamic Table have all operations from Materialized Views, and it must do. They are same as GPDB's external table and foreign table, if you have a try: ```sql create external table ext1; drop external table ext1; drop foreign table ext1; ``` Both will succeed, external table is actually a foreign table. We provide gram sugar for that CREATE/DROP, but not all command or all message infos, if users want to use Materialized Views command, that's no problem. > Maybe we should create this relation as CREATE DYNAMIC MATERIALIZED VIEW not TABLE? This should fix a lot of SQL ambiguity problems. We follow Snowflake, customers want to have Snowflake `Dynamic Tables` in CBDB, better use the same word. Please refer to Snowflake https://docs.snowflake.com/en/user-guide/dynamic-tables-intro and our discussion #706 for more details. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
