Re: Fix domain fast defaults on empty tables

jian he <jian(dot)universality(at)gmail(dot)com> writes:
> On Fri, Jun 5, 2026 at 10:08 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I think there's reason for concern here, which is that we do not throw
>> an error for the apparently equivalent case
>> regression=# create table t2 (a int, b d_div default 1);
>> CREATE TABLE
>> This will give you an error at INSERT, but not CREATE. So this
>> is inconsistent, as well as different from the pre-v19 behavior.

> However, this is normal behavior for non-domain types.
> create table t2 (a numeric default (1::numeric/0.0::float4)); -- ok
> alter table t2 add column b numeric default ((1::numeric/0.0::float4)); -- error

Well, that's not great either. The idea of avoiding evaluating
the default expression altogether when the table is empty could
ameliorate that problem too.

But my point stands: a0b6ef29a introduces different treatment for
domain-CHECK-constraint errors than other types of runtime errors
in the default expression. I think that is fundamentally the wrong
direction to go in. We want more consistency here, not less.

regards, tom lane