Horton

Re: support fast default for domain with constraints

jian he <jian.universality@gmail.com>

View thread View on postgr.es
From: jian he <jian.universality@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2025-05-19T07:05:04Z
Lists: pgsql-hackers

Attachments

On Mon, Mar 24, 2025 at 7:14 PM jian he <jian.universality@gmail.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.

Commits

  1. Enable fast default for domains with non-volatile constraints

  2. Extend DomainHasConstraints() to optionally check constraint volatility

  3. Restrict virtual columns to use built-in functions and types

  4. Replace EEOP_DONE with special steps for return/no return

  5. Add soft error handling to some expression nodes