Re: support fast default for domain with constraints

From: jian he <jian(dot)universality(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: support fast default for domain with constraints
Date: 2025-05-19 07:05:04
Message-ID: CACJufxGNCw51aeVxXOtgzgbE9J710e91umNzH-56rG5tmtK8mw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 24, 2025 at 7:14 PM jian he <jian(dot)universality(at)gmail(dot)com> wrote:
>
> v4-0003 table with empty rows aligned with master behavior.
> also will do table rewrite if the new column is domain with volatile
> check constraints,
> so less surprising behavior.

I found out that my v4-0003 is wrong.

For example, the following ALTER TABLE ADD COLUMN should not fail.
CREATE DOMAIN domain5 AS int check(value > 10) default 8;
CREATE TABLE t3(a int);
ALTER TABLE t3 ADD COLUMN b domain5 default 1; --ok, table rewrite

I also reduced the bloated tests.
summary of the behavior that is different from master:
if domain constraint is not volatile *and* domain's default expression satisfy
constraint's condition then no need table rewrite.

Attachment Content-Type Size
v5-0002-add-function-DomainHaveVolatileConstraints.patch text/x-patch 2.7 KB
v5-0003-fast-default-for-domain-with-constraints.patch text/x-patch 10.8 KB
v5-0001-soft-error-variant-of-ExecPrepareExpr-ExecInitExp.patch text/x-patch 3.9 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiro Ikeda 2025-05-19 08:17:55 Re: Assertion failure in smgr.c when using pg_prewarm with partitioned tables
Previous Message Amit Kapila 2025-05-19 06:48:04 Re: Make wal_receiver_timeout configurable per subscription