Re: Fix domain fast defaults on empty tables - Mailing list pgsql-hackers

From jian he
Subject Re: Fix domain fast defaults on empty tables
Date
Msg-id CACJufxH+qnnWaySKbJD8pBL5Q+aYFE+hffb6-byT_6uPRB1J2Q@mail.gmail.com
Whole thread
List pgsql-hackers
On Fri, Jun 5, 2026 at 10:08 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Heikki Linnakangas <hlinnaka@iki.fi> writes:
> > On 5 June 2026 10:48:00 EEST, Chao Li <li.evan.chao@gmail.com> wrote:
> >> 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 seems totally reasonable to get an error in that case. '1' is not a valid value for the datatype, whether or not
thereare any rows in the table. 
>
> 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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Fix DROP PROPERTY GRAPH "unsupported object class" error
Next
From: Michael Paquier
Date:
Subject: Re: bugfix - fix broken output in expanded aligned format, when data are too short