jian he <[email protected]> writes:
> On Fri, Jun 5, 2026 at 10:08 PM Tom Lane <[email protected]> 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
