Re: [PG19] Wrong results from NOT NULL-based expression simplification

Hi,

Richard, thanks for committing my fix and drafting the quick fix
for the first case.

> Regarding #2, this is a bug in v17 and later, not a v19 regression, so
> I don't think it should be a v19 open item. And it's in the MERGE
> code, so I think Dean is the right person to look at it, not me.

On #2, I agree the root cause is in 17. But the wrong result is new
in 19. The MERGE in my first mail returns t on 17 and 18, and f on
19. So I would like to keep it on the list.

Fujii, thanks for reviewing the fix.
> Codex reported that the following INSERT, which previously succeeded,
still
> fails with this patch. I confirmed the issue. Should we fix this as well?

I see this too. It works on 18 and on 62e46c00c65, and fails from
d8ce0050a on, with or without Richard's v1.

The NULLIF branch labels its result with the typmod the NULLIF had
before f(a) was inlined. The index expression was already inlined in
the relcache, so its NULLIF gets no label.

The attached patch goes on top of Richard's v1. It uses the typmod of
the simplified first argument.

Haibo, thanks for reviewing the 005.
> Without 0005, this returned 12 rows, as expected.
> With 0005, it returned 9.

I reproed that result too. But I agree with Richard
#5 is not a v19 item, I withdraw 0005 for now.

Let's finish the v19 open items first and have new thread to discuss that.

Thanks,
Shihao