Re: BUG #19445: Domain DEFAULT not recorded in pg_attrdef (atthasdef false) in PostgreSQL 18.3

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

In response to

Browse pgsql-bugs by date

  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)