Comments inline with column and table definition. And simple idempotent DDL. AFFIRM TABLE product_category ( category_id smallserial

Comments inline with column and table definition. And simple idempotent DDL. AFFIRM TABLE product_category ( category_id smallserial PRIMARY KEY , name text NOT NULL ) COMMENT 'Product categories from the official catalog' ; AFFIRM TABLE product ( product_id uuid PRIMARY KEY DEFAULT gen_random_uuid() WAS (id uuid DEFAULT gen_random_uuid()) , (id int8 DEFAULT gen_random_uuid() USING gen_random_uuid()) COMMENT 'Product lookup id' , category_id REFERENCES product_category ON UPDATE CASCADE ON DELETE RESTRICT NOT NULL COMMENT 'Product category' , serial_num text NOT NULL COMMENT 'Product serial number' ) COMMENT 'Our nifty products' WAS (products) ; Just like a SELECT statement describes the structure of the output with the engine figuring out how to retrieve it, instead of CREATE, CREATE IF NOT EXISTS, and ALTER statements over and over, just describe what your target is supposed to look like and let the engine reconcile. The WAS keyword (for example) could allow engines to figure out how to get from one state to the next. In this case converting the id column from an int8 to a UUIDv4 and then changing its name from id to product_id. The table was named products and is now product. No more Flyway or the like where you have to hunt through migration files to find the latest definition for a view or function. So much easier to diff when making changes. Then after all databases have been migrated, prune the old, obsolete WAS definitions. Also, why do we have to specify the type of category_id in the product table? It's a foreign key reference; the type is not only implied, it's mandatory to match exactly. But since we're already here on the topic: • Real pivot support, not that crosstab hack • System-versioned temporal tables • Append-only (log) tables • Unstored computed columns • Alter a table used in a view, so the view loses column(s) or gains • SELECT * EXCEPT (<column names>) • GROUP AUTO where the query uses any non-aggregate column(s) as the GROUP BY column(s) • Automatically updated materialized views • Access Postgres via WebSocket