Re: BUG #19445: Domain DEFAULT not recorded in pg_attrdef (atthasdef false) in PostgreSQL 18.3 - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #19445: Domain DEFAULT not recorded in pg_attrdef (atthasdef false) in PostgreSQL 18.3
Date
Msg-id 2544065.1774896570@sss.pgh.pa.us
Whole thread Raw
In response to BUG #19445: Domain DEFAULT not recorded in pg_attrdef (atthasdef false) in PostgreSQL 18.3  (PG Bug reporting form <noreply@postgresql.org>)
List pgsql-bugs
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



pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #19444: conkey field empty for domain NOT NULL constraint in pg_constraint (18.3)
Next
From: Tom Lane
Date:
Subject: Re: BUG #19446: Domain DEFAULT not reflected in system catalogs and information_schema (PG 18.3)