Re: Support for NO INHERIT to INHERIT state change with named NOT NULL constraints

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/