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
