]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Fix broken handling of domains in atthasmissing logic.
authorTom Lane <tgl@sss.pgh.pa.us>
Mon, 3 Mar 2025 17:43:29 +0000 (12:43 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Mon, 3 Mar 2025 17:43:29 +0000 (12:43 -0500)
commit1d180931cc3bcdf66608593884b06d270a6d65e5
treeff9656b0d9ad8cfe9a3905860d7ecda4b8e23e0b
parentc7303f01c574c3543c68452c7dfd8998efe25085
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.universality@gmail.com>
Author: jian he <jian.universality@gmail.com>
Author: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/CACJufxHFssPvkP1we7WMhPD_1kwgbG52o=kQgL+TnVoX5LOyCQ@mail.gmail.com
Backpatch-through: 13
src/backend/catalog/heap.c
src/backend/catalog/pg_attrdef.c
src/backend/commands/tablecmds.c
src/include/catalog/heap.h
src/test/regress/expected/fast_default.out
src/test/regress/sql/fast_default.sql