From: Tom Lane <tgl@sss.pgh.pa.us>
To: zheng_xianghang@163.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #19445: Domain DEFAULT not recorded in pg_attrdef (atthasdef false) in PostgreSQL 18.3
In-reply-to: <19445-f919d77c0e4f8d10@postgresql.org>
References: <19445-f919d77c0e4f8d10@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Mon, 30 Mar 2026 03:11:35 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2544064.1774896570.1@sss.pgh.pa.us>
Date: Mon, 30 Mar 2026 14:49:30 -0400
Message-ID: <2544065.1774896570@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/2544065.1774896570%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.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