Re: Adding a stored generated column without long-lived locks

On Fri, 2026-08-28 at 18:07 +0200, Alberto Piai wrote:
> Before this gets eventually picked up by a committer: I am having second
> thoughts about my choice to allow = in addition to IS NOT DISTINCT FROM.
>
> The patch can absolutely be reviewed with that in mind, I think.
> Removing support for = would be an isolated change which wouldn't affect
> the rest of the implementation.
>
> As it stands, I'd probably prefer it committed without that, and expand
> on the first commit at a later point.
>
> Anyway I'll try to find time to think about a more convincing proof (or
> a counterexample) over the next couple of days.

I think I see what you mean: this command exists exclusively so that users
can add a generated column to a bigger table without downtime. So they
will create the constraint specifically for this purpose, and it wouldn't
be a loss of functionality to force them to use IS NOT DISTINCT FROM.
Removing support for a constraint with = would simplify the code and the
documentation.

I won't object to that, but I like the patch as it is now.
I can imagine a case where somebody uses a regular column with a check
constraint and at some later point decides to turn the column into a
generated column. That user might be annoyed if they had to create a
second check constraint, since there already is a perfectly good one.

I'd say that if you remove support for =, you might as well also remove
support for check constraints in the shape "(expression IS NOT DISTINCT
FROM column)".

Yours,
Laurenz Albe