Re: NOT ENFORCED constraint feature

On Tue, Feb 4, 2025 at 7:22 PM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>
> On 03.02.25 06:19, Ashutosh Bapat wrote:
> > Here's how I see the state conversions happening.
> >
> > NOT VALID, NOT ENFORCED changed to NOT_VALID, ENFORCED - no data
> > validation required, constraint is enforced on the new tuples/changes
> > NOT VALID, ENFORCED changed to NOT VALID, NOT ENFORCED - no data
> > validation, constraint isn't enforced anymore
> > VALID, NOT ENFORCED changed to VALID, ENFORCED - data validation
> > required, constraint is enforced
> > VALID, ENFORCED changed to VALID, NOT ENFORCED - no data validation
> > required, constrain isn't enforced anymore, we rely on user to enforce
> > the constraint on their side
>
> This looks sensible to me.

Attached patch implemented this behaviour. To achieve this, we have to
revert (see 0007) some committed code and relax the restriction that
the NOT ENFORCED constraint must also be NOT VALID. Now, NOT ENFORCED
and NOT VALID are independent statuses, and the psql-meta meta command
will display NOT VALID alongside the NOT ENFORCED constraint.
Previously, we hid NOT VALID for NOT ENFORCED constraints, assuming it
would be implied, but that is no longer the case.

Apart from this, I have added a few more tests in 0009. Additionally,
I made some minor code rearrangements in the
AttachPartitionForeignKey() function -- was introduced in the 0002
refactoring patch. I kept these rearrangement changes separate in 0003
to highlight them, allowing the reviewer to identify any potential
issues, though I don't believe there are any. Of course, I could be
wrong.

Also, I need more time for additional testing of the 0008 and 0009
patches, which I plan to complete by the end of this week. Thanks.

Regards,
Amul