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

On Sun, Oct 11, 2026 at 10:50 AM Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> Codex reported that the following INSERT, which previously succeeded, still
> fails with this patch. I confirmed the issue. Should we fix this as well?

Thanks for the report. This is the same problem, this time in NULLIF.
A NULLIF's typmod is that of its first argument, and inlining the SQL
function changes it from -1 to that of numeric(10). The index expr is
inlined in the first pass but reduced only in the second, so it gets
the new typmod, while the ON CONFLICT expression is inlined and
reduced in one pass and keeps -1.

v2-0001 extends v1 to relabel a rebuilt NULLIF to its original typmod
as well, and to use that typmod when a NULLIF is folded to a constant.

While testing, I found that relabeling a rebuilt COALESCE defeats
reconsider_full_join_clause(), which expects the merged column of a
FULL JOIN USING to be a bare COALESCE. So when the join inputs are
inlined SQL functions, a qual like "x = 1" on the merged column is no
longer pushed down to them. v2-0002 fixes that by looking through the
RelabelType there.

- Richard