On Wed, 1 Oct 2025 at 01:12, Erki Eessaar <erki.eessaar@taltech.ee> wrote:
> However, the inconsistency I'm pointing out is that this "documentation-only" state appears to be modifiable for
FOREIGNKEY constraints (using ALTER TABLE ... ENFORCED), but not for CHECK constraints.
>
> This leads to the core of my question: Is this difference in behavior intentional?
At least going by the commit messages, it seems to be intentional:
From [1]:
Note that CHECK constraints do not currently support ALTER operations,
so changing the enforceability of an existing constraint isn't
possible without dropping and recreating it. This could be added
later.
And for foreign keys in [2]:
Conversely, if a NOT ENFORCED
foreign key constraint is changed to ENFORCED, the necessary triggers
will be created, and the will be changed to VALID by performing
necessary validation.
> If NOT ENFORCED constraints are not meant to be altered after creation, then it seems the ability to enforce a
foreignkey is the unexpected behavior. If they are meant to be alterable, then the failure to enforce a check
constraintseems to be the bug.
I think it would be good if the documents were to mention the
limitation with CHECK constraints. Otherwise, users are just going to
be left to discover this for themselves.
David
[1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=ca87c415e
[2] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=eec0040c4
