Re: BUG #19412: Wrong query result with not null constraint

On Fri, Feb 20, 2026 at 3:25 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I agree with this fix: I think the code is like it is simply because
> it didn't occur to me that the child Vars could have any nullingrel
> bits yet.  However, I don't agree that that comment needs no updates.
> I suggest something like
>
> -         * Below, we just propagate var->varnullingrels into the translated
> -         * Var.
> +         * Below, we just merge var->varnullingrels into the translated
> +         * Var.  (We must merge not just copy: the child Var could have
> +         * some nullingrel bits set already, and we mustn't drop those.)
>
> Also, I think I'd then drop the comment you added adjacent to the
> actual update; it seems redundant if the earlier comment says this.

Thanks for taking a look.  I've updated the comments as suggested,

> I agree with back-patching to v16.  This particular example doesn't
> misbehave in versions that don't have the drop-allegedly-redundant-
> NOT-NULL-tests logic, but the varnullingrels are certainly wrong
> all the way back, so possibly there are other examples that do
> misbehave in v16.

... and then pushed and back-patched to v16.

Thank you, Sergey, for the report and the excellent self-contained
repro query.  This is a great catch.  (I'm curious how you found this
bug -- was it from a production query or a fuzzing tool?)

- Richard