Fix broken handling of domains in atthasmissing logic. If a domain type has a default, adding a column of that type (without any explicit DEFAULT clause) failed to install the domain's default value in existing rows, instead leaving the new column null. This is unexpected, and it used to work correctly before v11. The cause is confusion in the atthasmissing mechanism about which default value to install: we'd only consider installing an explicitly-specified default, and then we'd decide that no table rewrite is needed.
To fix, take the responsibility for filling attmissingval out of StoreAttrDefault, and instead put it into ATExecAddColumn's existing logic that derives the correct value to fill the new column with. Also, centralize the logic that determines the need for default-related table rewriting there, instead of spreading it over four or five places. In the back branches, we'll leave the attmissingval-filling code in StoreAttrDefault even though it's now dead, for fear that some extension may be depending on that functionality to exist there. A separate HEAD-only patch will clean up the now-useless code. Reported-by: jian he <jian.universal...@gmail.com> Author: jian he <jian.universal...@gmail.com> Author: Tom Lane <t...@sss.pgh.pa.us> Discussion: https://postgr.es/m/CACJufxHFssPvkP1we7WMhPD_1kwgbG52o=kqgl+tnvox5lo...@mail.gmail.com Backpatch-through: 13 Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/aac07b56256e96f42b6d477e0a21c1266e3ffe15 Modified Files -------------- src/backend/catalog/heap.c | 69 +++++++++++++++++++++--- src/backend/commands/tablecmds.c | 85 ++++++++++++++++++++---------- src/include/catalog/heap.h | 5 +- src/test/regress/expected/fast_default.out | 65 +++++++++++++++++++++++ src/test/regress/sql/fast_default.sql | 44 ++++++++++++++++ 5 files changed, 233 insertions(+), 35 deletions(-)
