Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wVVEF-0020b7-0P for pgsql-hackers@arkaria.postgresql.org; Fri, 05 Jun 2026 14:08:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wVVEE-00ClUt-0F for pgsql-hackers@arkaria.postgresql.org; Fri, 05 Jun 2026 14:08:54 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wVVED-00ClUl-2b for pgsql-hackers@lists.postgresql.org; Fri, 05 Jun 2026 14:08:53 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wVVEC-00000001FPY-0Haq for pgsql-hackers@lists.postgresql.org; Fri, 05 Jun 2026 14:08:52 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.18.1/8.18.1) with ESMTP id 655E8TvJ3590552; Fri, 5 Jun 2026 10:08:29 -0400 From: Tom Lane To: Heikki Linnakangas cc: pgsql-hackers@lists.postgresql.org, Chao Li , Andrew Dunstan , jian he Subject: Re: Fix domain fast defaults on empty tables In-reply-to: <219843CF-9B49-404A-838D-88D51902B978@iki.fi> References: <7033D663-DDB4-4B35-922C-F33DE53B1502@gmail.com> <219843CF-9B49-404A-838D-88D51902B978@iki.fi> Comments: In-reply-to Heikki Linnakangas message dated "Fri, 05 Jun 2026 12:04:52 +0300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3590550.1780668509.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Fri, 05 Jun 2026 10:08:29 -0400 Message-ID: <3590551.1780668509@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Heikki Linnakangas writes: > On 5 June 2026 10:48:00 EEST, Chao Li wrote: >> 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 > It seems totally reasonable to get an error in that case. '1' is not a v= alid value for the datatype, whether or not there are any rows in the tabl= e. 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. Concretely, I'm pretty sure it is a hazard for pg_dump, which thinks it can freely transform bits of CREATE operations into ALTERs. I didn't try to make an example case, but I suspect it is now possible to create a database that will fail dump/restore because of this inconsistency. regards, tom lane