public inbox for [email protected]help / color / mirror / Atom feed
pgsql: Fix broken handling of domains in atthasmissing logic. 6+ messages / 1 participants [nested] [flat]
* pgsql: Fix broken handling of domains in atthasmissing logic. @ 2025-03-03 17:44 Tom Lane <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-03-03 17:44 UTC (permalink / raw) To: [email protected] 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 <[email protected]> Author: jian he <[email protected]> Author: Tom Lane <[email protected]> Discussion: https://postgr.es/m/CACJufxHFssPvkP1we7WMhPD_1kwgbG52o=kQgL+TnVoX5LOyCQ@mail.gmail.com Backpatch-through: 13 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/edc3bccd0dc79f874bd10ed6206aed7028df6fcf Modified Files -------------- src/backend/catalog/heap.c | 62 +++++++++++++++++++--- src/backend/catalog/pg_attrdef.c | 6 +++ 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 ++++++++++++++++ 6 files changed, 233 insertions(+), 34 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix broken handling of domains in atthasmissing logic. @ 2025-03-03 17:44 Tom Lane <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-03-03 17:44 UTC (permalink / raw) To: [email protected] 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 <[email protected]> Author: jian he <[email protected]> Author: Tom Lane <[email protected]> Discussion: https://postgr.es/m/CACJufxHFssPvkP1we7WMhPD_1kwgbG52o=kQgL+TnVoX5LOyCQ@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(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix broken handling of domains in atthasmissing logic. @ 2025-03-03 17:44 Tom Lane <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-03-03 17:44 UTC (permalink / raw) To: [email protected] 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 <[email protected]> Author: jian he <[email protected]> Author: Tom Lane <[email protected]> Discussion: https://postgr.es/m/CACJufxHFssPvkP1we7WMhPD_1kwgbG52o=kQgL+TnVoX5LOyCQ@mail.gmail.com Backpatch-through: 13 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/c75c830e23929141b80b0f13612f2796254bd27d Modified Files -------------- src/backend/catalog/heap.c | 67 ++++++++++++++++++++--- 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, 232 insertions(+), 34 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix broken handling of domains in atthasmissing logic. @ 2025-03-03 17:44 Tom Lane <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-03-03 17:44 UTC (permalink / raw) To: [email protected] 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 <[email protected]> Author: jian he <[email protected]> Author: Tom Lane <[email protected]> Discussion: https://postgr.es/m/CACJufxHFssPvkP1we7WMhPD_1kwgbG52o=kQgL+TnVoX5LOyCQ@mail.gmail.com Backpatch-through: 13 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/1d180931cc3bcdf66608593884b06d270a6d65e5 Modified Files -------------- src/backend/catalog/heap.c | 62 +++++++++++++++++++--- src/backend/catalog/pg_attrdef.c | 6 +++ 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 ++++++++++++++++ 6 files changed, 233 insertions(+), 34 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix broken handling of domains in atthasmissing logic. @ 2025-03-03 17:44 Tom Lane <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-03-03 17:44 UTC (permalink / raw) To: [email protected] 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 <[email protected]> Author: jian he <[email protected]> Author: Tom Lane <[email protected]> Discussion: https://postgr.es/m/CACJufxHFssPvkP1we7WMhPD_1kwgbG52o=kQgL+TnVoX5LOyCQ@mail.gmail.com Backpatch-through: 13 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/95f650674d2ceea1ba6440a9b0ae89ed3867fd7e Modified Files -------------- src/backend/catalog/heap.c | 62 ++++++++++++++++++--- src/backend/catalog/pg_attrdef.c | 6 +++ src/backend/commands/tablecmds.c | 87 ++++++++++++++++++++---------- src/include/catalog/heap.h | 5 +- src/test/regress/expected/fast_default.out | 65 ++++++++++++++++++++++ src/test/regress/sql/fast_default.sql | 44 +++++++++++++++ 6 files changed, 235 insertions(+), 34 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix broken handling of domains in atthasmissing logic. @ 2025-03-03 17:44 Tom Lane <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-03-03 17:44 UTC (permalink / raw) To: [email protected] 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 <[email protected]> Author: jian he <[email protected]> Author: Tom Lane <[email protected]> Discussion: https://postgr.es/m/CACJufxHFssPvkP1we7WMhPD_1kwgbG52o=kQgL+TnVoX5LOyCQ@mail.gmail.com Backpatch-through: 13 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/d6dd2a02bae0d67ff6fbd73068dc36d0b82fc14b Modified Files -------------- src/backend/catalog/heap.c | 62 +++++++++++++++++++--- src/backend/catalog/pg_attrdef.c | 6 +++ 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 ++++++++++++++++ 6 files changed, 233 insertions(+), 34 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2025-03-03 17:44 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-03-03 17:44 pgsql: Fix broken handling of domains in atthasmissing logic. Tom Lane <[email protected]> 2025-03-03 17:44 pgsql: Fix broken handling of domains in atthasmissing logic. Tom Lane <[email protected]> 2025-03-03 17:44 pgsql: Fix broken handling of domains in atthasmissing logic. Tom Lane <[email protected]> 2025-03-03 17:44 pgsql: Fix broken handling of domains in atthasmissing logic. Tom Lane <[email protected]> 2025-03-03 17:44 pgsql: Fix broken handling of domains in atthasmissing logic. Tom Lane <[email protected]> 2025-03-03 17:44 pgsql: Fix broken handling of domains in atthasmissing logic. Tom Lane <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox