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

On Fri, Feb 20, 2026 at 3:25 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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