| | 18 | |
| | 19 | I would also cast doubt about the `db_default` approach unless someone can confirm it works on all backends. From my understanding MySQL and Postgres can achieve instant columns addition with `DEFAULT` when the value is a constant (non-volatile) by storing the value in their table catalog and resolving the absence of value in the table tuples as the default. I can't see how this is possible when the value is not constant per row like it's the case with `gen_random_uuid`. |
| | 20 | |
| | 21 | Per Postgres [https://www.postgresql.org/docs/current/sql-altertable.html#SQL-ALTERTABLE-NOTES docs] |
| | 22 | |
| | 23 | > Adding a column with **a volatile** `DEFAULT` (e.g., clock_timestamp()), a stored generated column, an identity column, or a column with a domain data type that has constraints **will cause the entire table and its indexes to be rewritten**. Adding a virtual generated column never requires a rewrite. |
| | 24 | |
| | 25 | A full table rewrite in a transaction will cause the same issues as manually issuing a single `UPDATE` statement and should be avoided. |