Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\))
Subject: Re: Fix domain fast defaults on empty tables
From: Chao Li <li.evan.chao@gmail.com>
In-Reply-To: <219843CF-9B49-404A-838D-88D51902B978@iki.fi>
Date: Fri, 5 Jun 2026 17:52:54 +0800
Cc: pgsql-hackers@lists.postgresql.org,
 Andrew Dunstan <andrew@dunslane.net>,
 jian he <jian.universality@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1A33470E-FCAE-42F0-8790-EE928058262B@gmail.com>
References: <7033D663-DDB4-4B35-922C-F33DE53B1502@gmail.com>
 <219843CF-9B49-404A-838D-88D51902B978@iki.fi>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Archived-At: 
 <https://www.postgresql.org/message-id/1A33470E-FCAE-42F0-8790-EE928058262B%40gmail.com>
Precedence: bulk


> On Jun 5, 2026, at 17:04, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>=20
>=20
>=20
> On 5 June 2026 10:48:00 EEST, Chao Li <li.evan.chao@gmail.com> wrote:
>> Hi,
>>=20
>> I tested "[a0b6ef29a] Enable fast default for domains with =
non-volatile constraints". After tracing some cases from the regression =
tests, I came up with this test case and found a bug:
>> ```
>> evantest=3D# create domain d_div as int check (1 / (value - 1) > 0);
>> CREATE DOMAIN
>> evantest=3D# create table t (a int);
>> CREATE TABLE
>> evantest=3D# alter table t add column b d_div default 1;
>> ERROR:  division by zero
>> ```
>>=20
>> It looks like errors inside the CHECK expression itself, such as the =
int4div division-by-zero in this test, are still hard errors that can =
fail the ALTER TABLE command.
>=20
> It seems totally reasonable to get an error in that case. '1' is not a =
valid value for the datatype, whether or not there are any rows in the =
table.
>=20
> - Heikki

I agree that rejecting the default is semantically reasonable. But the =
concern is that this is a user-visible behavior change, and the feature =
didn=E2=80=99t seem intended to make that change. Before a0b6ef29a, this =
ALTER TABLE command could succeed. If we now want to reject such =
defaults, I think that should be documented explicitly.

Also, there might be some practical use for the current behavior. For =
example, an invalid default can be used to prevent INSERT from omitting =
the column.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/