From: | jian he <jian(dot)universality(at)gmail(dot)com> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | bug when apply fast default mechanism for adding new column over domain with default value |
Date: | 2025-03-01 05:39:56 |
Message-ID: | CACJufxHFssPvkP1we7WMhPD_1kwgbG52o=kQgL+TnVoX5LOyCQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
hi.
While looking at ATExecAddColumn, I saw there are two DomainHasConstraints,
which are cache unfriendly,
then I think I found a bug for applying fast default over domain with
default value.
bug demo:
create domain int_domain3 as int check(value > 1) default 11;
create domain int_domain4 as int default 11;
drop table if exists t0;
create table t0(a int);
insert into t0 values(1),(2);
alter table t0 add column b int_domain3;
select * from t0;
a | b
---+----
1 | 11
2 | 11
(2 rows)
alter table t0 add column c int_domain4;
select * from t0;
a | b | c
---+----+---
1 | 11 |
2 | 11 |
(2 rows)
I expect column "c" value also be value 11.
column b type is domain int_domain3, which has a constraint.
As a result, adding column b triggers a table rewrite, ensuring the
domain default value is successfully applied.
column c is domain int_domain4, which has no constraint.
This allows for a fast default mechanism applied to column c, but we cannot.
StoreAttrDefault, pg_attrdef can not cope with domain with default expression.
also domain default expression is stored at pg_tye.typdefaultbin.
Attach a patch to fix this issue by cause it to table rewrite.
also minor refactor to avoid double DomainHasConstraints function call.
From | Date | Subject | |
---|---|---|---|
Next Message | Shankaran, Akash | 2025-03-01 06:23:39 | RE: SIMD optimization for list_sort |
Previous Message | Rahila Syed | 2025-03-01 04:49:01 | Improve monitoring of shared memory allocations |