| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | zheng_xianghang(at)163(dot)com |
| Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #19445: Domain DEFAULT not recorded in pg_attrdef (atthasdef false) in PostgreSQL 18.3 |
| Date: | 2026-03-30 18:49:30 |
| Message-ID: | 2544065.1774896570@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> When a table column uses a domain that has a DEFAULT value, the column's
> pg_attribute.atthasdef is false, and no entry exists in pg_attrdef.
> However, the domain default value works correctly at runtime.
> This is a system catalog metadata bug.
No, it is not, as demonstrated by the fact that the behavior is
correct. There is no default expression associated directly with the
table column, therefore it's correct that atthasdef is false.
If we did store a default there, that would be equivalent to
a case like
CREATE DOMAIN my_arr_domain AS int[] DEFAULT '{}';
CREATE TABLE t (col my_arr_domain DEFAULT '{}');
The problem with this is that the column-associated default
would override the domain-associated default, so that the
column's behavior would fail to track ALTER DOMAIN SET DEFAULT.
So the change you are proposing would create a bug not fix one.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2026-03-30 18:51:08 | Re: BUG #19446: Domain DEFAULT not reflected in system catalogs and information_schema (PG 18.3) |
| Previous Message | Tom Lane | 2026-03-30 18:44:18 | Re: BUG #19444: conkey field empty for domain NOT NULL constraint in pg_constraint (18.3) |