Re: Support for NO INHERIT to INHERIT state change with named NOT NULL constraints - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Support for NO INHERIT to INHERIT state change with named NOT NULL constraints
Date
Msg-id 202501080947.upnia6ptv4dm@alvherre.pgsql
Whole thread Raw
In response to Re: Support for NO INHERIT to INHERIT state change with named NOT NULL constraints  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 2024-Nov-25, Robert Haas wrote:

> In a simple implementation of ALTER TABLE this would be true, but I
> don't see why it should need to be true in ours. It should be possible
> to notice that there's an existing NOT NULL constraint and use that as
> evidence that the new one can be added without needing to revalidate
> the table contents. ALTER TABLE does similar things already. For
> instance, TryReuseIndex() can attempt to attach an existing index file
> to a new index definition without rebuilding it; TryReuseForeignKey
> can attempt to re-add a foreign key constraint without needing to
> revalidate it. But even more to the point, ATAddCheckNNConstraint and
> MergeWithExistingConstraint know about merging a newly-added
> constraint with a preexisting one without needing to revalidate the
> table.

I think you're explaining why we need this patch, which seems a bit
useless in the thread where this patch was posted.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Conflict detection for update_deleted in logical replication
Next
From: Aleksander Alekseev
Date:
Subject: Re: IANA timezone abbreviations versus timezone_abbreviations