bug when apply fast default mechanism for adding new column over domain with default value

Поиск
Список
Период
Сортировка
От jian he
Тема bug when apply fast default mechanism for adding new column over domain with default value
Дата
Msg-id CACJufxHFssPvkP1we7WMhPD_1kwgbG52o=kQgL+TnVoX5LOyCQ@mail.gmail.com
обсуждение исходный текст
Ответы Re: bug when apply fast default mechanism for adding new column over domain with default value
Список 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.



В списке pgsql-hackers по дате отправления: