| 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/
| 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 |