Why is it not recommended to use SELECT * in the definition of a materialized view?

• A. Because it's always better to specify the columns you want to show in the materialized view
• B. It guarantees real-time update of new base columns
• C. If new columns are added to the base table, those new columns are not automatically propagated to the materialized views
• D. It prevents any confusion about the underlying schema

Answer: (C)

The idea being tested is how a materialized view derives its structure from its defining SELECT. When you use SELECT *, the materialized view takes all columns that exist in the base table at the moment the MV is created, and that column list becomes fixed for the MV. If you later add new columns to the base table, those new columns don’t automatically become part of the materialized view. The MV’s schema won’t evolve with the base table—you’d have to redefining the MV with an explicit column list (or recreate it) to include or adjust columns.

Explicitly listing columns gives you deliberate control over exactly what is materialized, making maintenance predictable. It avoids schema drift where changes to the base table aren’t reflected in the MV, which is why the recommended practice is to avoid SELECT * in MV definitions.