Re: Fix domain fast defaults on empty tables

From: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Andrew Dunstan <andrew(at)dunslane(dot)net>, jian he <jian(dot)universality(at)gmail(dot)com>
Subject: Re: Fix domain fast defaults on empty tables
Date: 2026-06-05 09:52:54
Message-ID: 1A33470E-FCAE-42F0-8790-EE928058262B@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Jun 5, 2026, at 17:04, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>
>
>
> On 5 June 2026 10:48:00 EEST, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
>> Hi,
>>
>> 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=# create domain d_div as int check (1 / (value - 1) > 0);
>> CREATE DOMAIN
>> evantest=# create table t (a int);
>> CREATE TABLE
>> evantest=# alter table t add column b d_div default 1;
>> ERROR: division by zero
>> ```
>>
>> 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.
>
> 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.
>
> - 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’t 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/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message shveta malik 2026-06-05 10:02:41 Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication
Previous Message Daniel Gustafsson 2026-06-05 09:45:28 Re: Unexpected message truncation in WaitForAllTransactionsToFinish