Re: support fast default for domain with constraints - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: support fast default for domain with constraints
Date
Msg-id bba5e471-d122-45e2-8c8b-6421804c2043@dunslane.net
Whole thread Raw
In response to Re: support fast default for domain with constraints  (jian he <jian.universality@gmail.com>)
Responses Re: support fast default for domain with constraints
List pgsql-hackers
On 2026-01-26 Mo 2:52 AM, jian he wrote:
> On Mon, Sep 1, 2025 at 2:27 PM jian he <jian.universality@gmail.com> wrote:
>> summary of the attached v7.
>> v7-0001, v7-00002: preparatory patch.
>> v7-0003 adds fast default support for ALTER TABLE ADD COLUMN when the domain has
>> non-volatile constraints.
>> A table rewrite is still required for domains with volatile constraints.
>>
>> v7-0004 skip table rewrite (table scan only) for ALTER TABLE ADD
>> COLUMN with domains has volatile constraints.
>>
> Hi.
>
> rebase, and further simplified.
>
> maybe we could perform a table scan for ALTER TABLE ADD COLUMN when the domain
> has volatile constraints like v7-0004, avoiding a table rewrite.
> However, this approach
> feels inelegant, so I do not plan to pursue it.
>
> So, the fast default now applies to domains with non-volatile constraint
> expressions only.
>
> Regarding the prior discussion about empty table behavior. This patch is
> consistent with the master: not throwing an error if the default would fail the
> domain constraints.
>
>
>


here's an updated patch set.


main changes:


. renamed DomainHaveVolatileConstraints renamed to 
DomainHasVolatileConstraints, improved the comments and code structure

. squashed two commits into one, as there's only one user for the 
soft-error functions

. rename  ExecPrepareExprExtended to ExecPrepareExprWithContext and 
ExecInitExprExtended to ExecInitExprWithContext, with improved comments.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Shutdown indefinitely stuck due to unflushed FPI_FOR_HINT record
Next
From: Frédéric Yhuel
Date:
Subject: n_dead_tup could be way off just after a vacuum