From: Tom Lane <tgl@sss.pgh.pa.us>
To: jian he <jian.universality@gmail.com>
cc: Heikki Linnakangas <hlinnaka@iki.fi>, pgsql-hackers@lists.postgresql.org,
        Chao Li <li.evan.chao@gmail.com>, Andrew Dunstan <andrew@dunslane.net>
Subject: Re: Fix domain fast defaults on empty tables
In-reply-to: 
 <CACJufxH+qnnWaySKbJD8pBL5Q+aYFE+hffb6-byT_6uPRB1J2Q@mail.gmail.com>
References: <7033D663-DDB4-4B35-922C-F33DE53B1502@gmail.com>
 <219843CF-9B49-404A-838D-88D51902B978@iki.fi>
 <3590551.1780668509@sss.pgh.pa.us>
 <CACJufxH+qnnWaySKbJD8pBL5Q+aYFE+hffb6-byT_6uPRB1J2Q@mail.gmail.com>
Comments: In-reply-to jian he <jian.universality@gmail.com>
	message dated "Mon, 08 Jun 2026 08:33:53 +0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <578686.1780942335.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 08 Jun 2026 14:12:15 -0400
Message-ID: <578687.1780942335@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/578687.1780942335%40sss.pgh.pa.us>
Precedence: bulk

jian he <jian.universality@gmail.com> writes:
> On Fri, Jun 5, 2026 at 10:08=E2=80=AFPM Tom Lane <tgl@sss.pgh.pa.us> wro=
te:
>> I think there's reason for concern here, which is that we do not throw
>> an error for the apparently equivalent case
>> regression=3D# 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